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Unification  of  Larch  and  Z-Based  Object  Models 
To  Support  Algebraically-Based 
Design  Refinement; 

The  Larch  Perspective 

I.  Introduction 

1.1  Background 

The  software  development  community  has  progressed  from  producing  batch-oriented, 
single  application  programs  to  delivering  highly  distributed,  parallel  applications.  As 
software  systems  grow  in  sophistication,  capturing  software  requirements  with  precision 
becomes  imperative.  In  spite  of  this  requirement,  most  specifications  are  written  using 
natural  languages  such  as  English  text  and  graphical  notations.  These  specifications  are 
ambiguous  and  imprecise  leaving  them  open  to  interpretation  (NS91).  In  addition,  infor¬ 
mal  specifications  exacerbate  the  development  process  by  causing  software  designers  to 
miss  requirements  and  by  increasing  the  risk  of  delivering  an  undesired  product. 

Therefore,  in  an  attempt  to  introduce  rigor  into  the  specification  process,  software 
researchers  are  developing  and  applying  formal  specification  techniques.  Formal  specifi¬ 
cation  languages  are  precise  and  unambiguous  because  they  are  based  on  fundamental 
mathematical  constructs  such  as  set  theory  and  predicate  logic  (Win87).  These  languages 
provide  software  engineers  with  the  capability  to  express  complex  ideas  in  a  concise  fash¬ 
ion  (NS91).  In  addition,  software  engineers  can  reason  about  their  specifications  and  form 
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proofs  of  correctness  (NS91).  Thus,  this  theoretical  basis  provides  the  clarity  and  precision 
required  for  specifying  software  systems  (Sri91). 

Although  formal  specification  languages  provide  a  powerful  mechanism  for  analyzing 
and  defining  a  software  problem,  many  software  developers  are  leery  of  the  approach. 
They  claim  that  formal  techniques  require  a  sophisticated  mathematics  background  and 
take  too  long  to  learn  (Hal90).  More  importantly,  they  find  it  difficult  to  communicate  the 
mathematical  description  to  a  system’s  user.  Consequently,  many  software  developers  rely 
on  a  less  rigorous  object-oriented  approach  during  the  specification  phase. 

In  the  last  decade,  object-oriented  methods  have  emerged  as  a  practical  way  to 
organize  information  about  a  problem  (RBP'''91).  Developers  use  object-oriented  models 
to  analyze  a  system  by  decomposing  it  into  smaller,  more  manageable  modules.  In  addition, 
object-oriented  models  help  a  system’s  user  visualize  his  system.  Therefore,  the  use  of  these 
models  has  become  one  of  the  preferred  methods  for  documenting  software  requirements. 

To  exploit  the  strengths  of  both  the  practical  object-oriented  approach  and  the  more 
precise  theory-based  perspective,  the  software  engineering  community  is  exploring  ways  to 
formally  extend  the  object-oriented  analysis  process.  A  proposed  approach  is  being  devel¬ 
oped  at  the  Air  Force  Institute  of  Technology  (AFIT)  by  the  Knowledge-Based  Software 
Engineering  (KBSE)  research  group.  To  date,  the  group  has  developed  a  domain-specific 
application  composition  system  that  relies  on  an  object-oriented  approach  for  document¬ 
ing  domain  knowledge.  This  domain  knowledge  is  translated  into  an  object-based  envi¬ 
ronment  known  as  Software  Refinery^-''^  using  Refine,  a  wide-spectrum.  Lisp-based 
specification  language.  Once  the  domain  objects  have  been  defined.  Architect,  an  appli- 
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cation  composition  system  based  on  a  formalized  software  architecture,  composes  domain 
specific  applications  with  its  toolkit  of  components,  connectors,  and  constraints.  These 
applications  can  be  executed  simulating  a  specification’s  behavior  and  allowing  specifiers 
to  evaluate  whether  the  demonstrated  behavior  matches  the  desired  behavior. 

The  advances  achieved  in  the  KBSE  object-based  work  have  led  to  next-generation  re¬ 
search  in  integrating  formal  methods  with  object-oriented  analysis  and  design  techniques. 
Figure  1.1  shows  two  complementary  efforts  that  explore  the  feasibility  of  transforming 
object-oriented  models  into  formal  representations.  The  right  path  employs  an  algebraic- 
based  approach  for  specifying  object-oriented  models  while  the  left  path  establishes  a 
Z-based  framework.  Coupled  with  these  two  object  transformations  is  a  unification  mech¬ 
anism  that  produces  a  unified  abstract  framework.  The  basis  for  a  unified  model  is  to 
reduce  algebraic  and  Z  specifications  into  a  canonical  representation  establishing  a  gen¬ 
eral  model  for  formalized  object  models  and  promoting  the  notion  of  class-based  solutions. 
Two  paths  are  possible  from  the  unification  phase,  a  design  refinement  phase  and  an  ex- 
ecutability  analysis  phase.  The  design  refinement  phase  refines  an  abstract  specification 
into  a  concrete  description  providing  an  adequate  interface  into  the  design  process.  The 
executability  analysis  phase  establishes  an  execution  framework  for  a  specification  allowing 
a  specification  to  be  demonstrated  and  validated. 

1.2  Problem 

This  research  studies  the  algebraic- based  perspective,  the  right  path  in  Figure  1.1, 
focusing  on  the  following  objective: 
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Figure  1.1  Formalized  Object  Transformations 


Formally  extend  object-oriented  analysis  models  using  algebraic  specifications  to 
create  an  executable  framework,  while  incorporating  a  unification  with  Z-based 
models. 


Accomplishing  this  objective  requires  a  three-step  process.  First,  an  algebraic  frame¬ 
work  for  object-oriented  analysis  models  needs  to  be  established.  While  this  research 
addresses  formalizing  object  models  using  algebras,  Wabiszewski  is  expanding  the  Z-based 
perspective  (Wab94).  These  paths  are  linked  by  a  cooperative  effort  in  creating  a  unifying 
abstract  framework.  Therefore,  the  second  step  focuses  on  analyzing  the  similarities  and 
differences  between  algebraic  and  Z  specifications  to  design  a  unified  model.  In  order  to 
scope  the  remainder  of  this  study,  the  final  step  concentrates  on  creating  a  stable  execu¬ 
tion  framework  based  on  the  unified  model.  The  design  refinement  phase  is  left  for  future 
research. 
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1.3  Research  Approach 


For  this  study,  Rumbaugh’s  Object  Modeling  Technique  (OMT)  (RBP+Ql)  was  se¬ 
lected  as  the  object-oriented  approach  because  of  the  researcher’s  familiarity  with  the 
technique  as  well  as  concurrent  work  that  uses  the  Rumbaugh  method  (Wab94).  To  meet 
the  research  objective  described  in  Section  1.2,  the  following  approach  has  been  established: 

1.  Design  and  develop  an  algebraic  transformation  process  using  object-oriented  analysis 
(OOA)  models  as  the  source  representation  and  algebraic  specifications  as  the  target 
representation. 

(a)  Select  an  appropriate  algebraic  language  for  the  target  framework. 

(b)  Establish  an  evolutionary  approach  for  the  design  and  development  of  the  trans¬ 
formation  process. 

(c)  Identify  and  document  the  strengths  and  weaknesses  in  the  transformation  pro¬ 
cess. 

2.  Analyze  the  complementary  paths  shown  in  Figure  1.2  and  develop  a  unifying  ab¬ 
stract  structure. 

3.  Design  an  initial  execution  framework  based  on  the  unified  model. 

1.4  Sequence  of  Presentation 

The  remainder  of  this  thesis  is  organized  as  follows: 
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Chapter  II  reviews  Rumbaugh’s  Object  Modeling  Technique  and  the  current  liter¬ 
ature  in  the  field  of  algebraic  specifications.  This  literature  review  also  presents  several 
approaches  for  formalizing  object-oriented  techniques. 

Chapter  III  describes  an  evolutionary  development  approach  for  the  formal  object 
transformation  process,  presents  the  algebraic  transformation  phase,  and  introduces  the 
formal  execution  phase.  In  addition,  the  validation  domains  for  the  transformation  process 
are  described. 

Chapter  IV  contains  a  design  and  implementation  of  an  algebraic  language  parser. 

Chapter  V  describes  the  motivation  behind  establishing  a  unified  abstract  model 
and  presents  a  design  and  implementation  of  the  Unified  Model.  Additionally,  this  chapter 
describes  the  validation  process  for  the  unified  abstract  framework. 

Chapter  VI  presents  an  initial  design  and  implementation  of  a  formal  execution 
framework  for  Larch  and  Z. 

Chapter  VII  contains  general  conclusions  and  future  recommendations  for  research 
in  this  area. 

Several  appendices  are  included  to  provide  additional  information. 
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II.  Literature  Review 


2. 1  Introduction 

To  support  the  research  goals  outlined  in  Chapter  I,  this  chapter  reviews  two  relevant 
topics:  Rumbaugh’s  (RBP+91)  object-oriented  analysis  method  and  the  origin  and  evo¬ 
lution  of  algebraic  specifications.  Rumbaugh’s  Object  Modeling  Technique  (OMT)  is  the 
source  for  the  formal  object  transformation  process,  and  Section  2.2  describes  the  OMT 
analysis  models  and  their  key  object-oriented  characteristics.  After  establishing  an  under¬ 
standing  of  the  source  model,  Section  2.3  examines  the  feasibility  of  formally  representing 
OMT  models  using  algebraic  specifications.  Finally,  Section  2.4  evaluates  three  approaches 
for  formalizing  the  object-oriented  methodology. 

2.2  The  Rumbaugh  Object  Modeling  Technique  (OMT) 

OMT  is  an  object-oriented  methodology  that  focuses  on  software  analysis  using  three 
models  to  scope  an  application  domain.  These  models  represent  the  structural  organization 
of  the  domain,  the  reactive  behavior  of  the  domain,  and  the  data  transformations  of  the 
domain.  The  models  are  named  the  object,  dynamic,  and  functional  models,  respectively. 
The  object  model  is  the  keystone  for  the  OMT  analysis  process  and  provides  a  foundation 
from  which  to  construct  the  dynamic  and  functional  models.  Together  these  models  form 
the  framework  for  organizing  and  representing  domain  information. 

2.2.1  OMT  Object  Models.  The  object  model  captures  the  structure  of  a  soft¬ 
ware  domain  by  identifying  the  important  objects,  attributes,  and  associations  between 
objects  (RBP+91).  Two  important  associations  in  the  object  model  are  inheritance  and 
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Figure  2.1  Faculty  and  Student  Object  Model 


aggregation.  Inheritance  establishes  an  “is-a”  relationship  between  a  general  object  and  its 
specialization.  Aggregation  identifies  the  “is-composed-of”  relationship  associating  an  as¬ 
sembly  with  its  individual  components  (RBP'*'91).  Based  on  these  associations,  the  object 
model  communicates  the  organization  and  important  dependencies  of  a  software  system  to 
the  software  developer.  At  the  end  of  the  object  modeling  phase,  an  object  model  diagram 
and  associated  data  dictionary  are  produced.  As  an  example,  an  object  model  depicting  an 
inheritance  relationship  and  association  between  the  person,  faculty,  and  student  objects 
is  shown  in  Figure  2.1  (HB94). 

2.2.2  OMT  Dynamic  Models.  The  OMT  dynamic  model  uses  two  fundamental 
modeling  abstractions:  events  and  states  to  model  an  object’s  overall  state  space  and 
subspaces.  An  event  represents  external  stimuli  that  causes  an  object  to  behave  in  a 
certain  manner.  An  object’s  state  represents  the  current  values  of  an  object’s  attributes 
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Birthday  [age  <  17]  Birthday  [age  <  64]  Birthday 


after  an  event  has  occurred.  Consequently,  an  object  may  have  several  states  based  on 
the  number  of  events  and  corresponding  state  transitions.  In  the  end,  this  phase  generates 
two  products:  a  set  of  dynamic  models  representing  a  domain’s  state  space  and  several 
corresponding  state  transition  tables  describing  the  sequence  of  events.  In  relation  to  the 
person  object  model  described  in  the  previous  section.  Figure  2.2  (HB94)  shows  a  dynamic 
model  for  describing  the  various  states  of  a  person  as  a  person  ages,  i.e.,  child,  adult,  and 
senior.  Table  2.1  illustrates  a  simplified  state  transition  table. 


Table  2.1  Person  State  Transition  Table. 


Current  State 

.Event 

Parameters 

Guard 

Next  State 

Action 

Child 

Child 

Child 

Birthday 

Birthday 

death 

m 

Child 

Adult 

Terminated 

Birthday 

Birthday 

death 

age  <  64 
age  =  64 

Adult 

Senior 

Terminated 

Senior 

Senior 

Birthday 

death 

Senior 

Terminated 
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2.2.3  OMT  Functional  Models.  Rumbaugh  uses  the  functional  model  to  describe 
the  operations  defined  in  the  object  model  and  the  actions  defined  in  the  dynamic  model 
(RBP+91).  Data  transformation  is  the  functional  model’s  central  concept;  the  transfor¬ 
mation  is  used  to  compute  an  object’s  output  values  from  input  values  to  determine  an 
object’s  state.  In  addition,  the  functional  model  identifies  all  of  the  key  consumers  and 
producers  of  an  object’s  data.  The  products  from  this  phase  consist  of  a  set  of  data  flow 
diagrams.  Completing  the  person  example,  Figure  2.3  (HB94)  shows  a  functional  model 
computing  the  age  attribute  for  a  person. 


Person  Calendar 

Figure  2.3  Age  Data  Flow  Model 

2.2.4  OMT  Summary.  The  object,  dynamic,  and  functional  models  represent 
the  OMT  products  developed  during  software  analysis.  Depending  on  the  type  of  system 
to  be  modeled,  some  of  the  three  model  types  are  not  necessary.  For  example,  database 
systems  store  and  retrieve  data,  but  these  systems  do  not  have  extensive  functional  mod¬ 
els  since  data  transformations  do  not  take  place  (RBP'*‘91).  On  the  other  hand,  compilers 
translate  one  language  into  another  language  and  have  intensive  data  transformation  sys¬ 
tems  requiring  extensive  functional  models  (RBP'^91).  As  software  developers  begin  to 
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understand  each  OMT  model’s  purpose  and  relationship  to  the  other  models,  the  OMT 
process  assists  them  in  documenting  their  software  requirements  more  completely. 

2.3  Algebraic  Specifications 

Algebraic  specifications  are  a  formal  technique  using  equational  logic  as  its  syntactic 
domain  and  universal  algebra  and  category  theory  for  its  semantic  domain  (EMC092).  The 
algebraic  notation  consists  of  a  signature  that  defines  the  sorts  and  operators  and  a  set  of 
axiomatic  equations  that  specify  an  operator’s  behavior.  Originally  intended  for  describing 
data  types  in  an  implementation  independent  manner,  algebraic  specifications  have  evolved 
to  encompass  the  entire  specification  phase  (EMC092).  The  following  subsection  describes 
this  evolution. 

2.3.1  Using  Algebraic  Theories  to  Specify  Data  Types,  Algorithms,  and  Architec¬ 
tures.  Formal  methods  researchers  first  used  algebraic  specification  techniques  to  define 
the  behavior  of  abstract  data  types  because  they  believed  that  data  types  could  be  mod¬ 
eled  as  many-sorted  algebras  (EM092).  Thus,  they  used  algebraic  specifications  with  two 
goals  in  mind; 

•  structure  abstract  data  types  (ADTs)  as  a  notion  of  classes 

•  hide  the  implefnentation  dependent  details  by  focusing  on  the  ADT’s  behavior  and 
abstract  data  structure 

These  goals  established  the  importance  of  specifying  data  types  algebraically,  improving 
the  understanding  and  precision  of  abstract  data  types  and  promoting  software  reuse. 
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spec  Sorting  = 
based  on 

Bag,  Sequence,  Order 
operations 

sort:  Bag  — >  Sequence 
axioms 

sort(b)  =  s  if  b  =  seq-to-bag(s) 

A  X  precedes  y  in  s  ^  x  <  y 

Figure  2.4  A  Specification  for  Sorting 

As  researchers  gained  experience  in  formally  modeling  ADTs,  they  began  investigat¬ 
ing  the  feasibility  of  formally  specifying  algorithms.  Researchers  realized  that  algebraic 
theories  were  well-suited  for  describing  the  fundamental  properties  of  algorithms  (Sri91) 
(Smi90).  Srinivas  demonstrated  this  by  formally  modeling  the  sort  algorithm  (Sri91),  as 
depicted  in  Figure  2.4  (Sri91).  He  based  the  sort  theory  on  the  following  properties:  a  bag, 
a  sequence,  and  an  order.  After  specifying  the  essential  properties,  Srinivas  defined  a  sort 
function  using  a  sort  operator  with  a  bag  of  random  elements  as  its  domain  and  a  sequence 
of  elements  as  its  co-domain.  To  complete  this  specification,  he  used  an  axiomatic  equation 
to  preserve  the  property  of  the  sequence. 

The  abstract  sort  specification  in  Figure  2.4  demonstrates  the  concise  and  exact 
nature  of  describing  algorithms  algebraically.  This  specification  can  be  checked  for  con¬ 
sistency  by  deriving  a  set  of  algebraic  equations  from  the  specification’s  axiom.  These 
equations  are  derived  under  the  closure  of  logical  implication,  verifying  that  the  axiom 
does  not  violate  any  mathematical  properties. 

Another  important  feature  in  formally  specifying  algorithms  and  data  types  is  the 
notion  of  a  co-limit  (Smi90).  A  co-limit  is  a  category  theory  operation  used  to  combine 
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algebraic  specifications  on  a  shared  part  (e.g.,  an  algorithm  theory  and  a  problem  theory) 
(Smi90).  This  shared  union  produces  a  specialized  theory  presentation  containing  fea¬ 
tures  from  both  parent  theories.  This  notion  is  a  powerful  concept  for  composing  systems 
formally. 

With  the  advances  achieved  in  specifying  algorithms  algebraically,  several  other  re¬ 
searchers  are  exploring  the  notion  of  formally  specifying  architectures  and  domains.  Gerken 
hypothesizes  that  algebraic  specifications  can  formalize  the  fundamental  characteristics  of 
software  architectures  (Ger93).  He  is  currently  developing  a  method  to  describe  architec¬ 
tures  using  formally  specified  notions  of  components  and  connectors.  Other  researchers 
are  working  on  formalizing  domain  information.  Many  believe  domains  are  essentially  a 
collection  of  “types”  (Sri91)  that  can  be  formally  used,  modified,  and  combined  to  repre¬ 
sent  a  domain  (Bre91).  The  ability  to  compose  systems  and  the  potential  to  specify  more 
complex  domains  make  algebraic  specifications  a  powerful  notation  for  defining  a  software 
system. 

2.3.2  Algebraic  Specification  Languages.  Algebraic  specification  languages  sup¬ 
port  the  development  of  data  type,  algorithm,  and  architecture  theories  using  a  three-tuple 
notation  consisting  of  a  set  of  sort  symbols,  S,  a  set  of  operations,  OP,  and  a  set  of  equa¬ 
tions,  E  (EMC092): 

SPEC  =  (S,  OP,  E) 

The  following  subsections  examine  two  algebraic  languages  in  detail,  Obj  and  Larch, 
providing  a  general  understanding  of  each  language’s  syntcix  and  semantics. 
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2.3.2. 1  Obj.  Similar  to  the  class  hierarchy  notion  in  object-oriented  lan¬ 
guages,  the  theory  behind  Obj  is  to  support  the  notion  of  algebraically  specified  hierar¬ 
chical  models  (FGJM85).  Obj  is  a  functional  language  based  on  order-sorted  equational 
logic  and  parameterized  programming  with  an  emphasis  on  the  execution  of  algebraic 
specifications  (Win91).  Listed  below  are  the  features  in  the  language: 

1.  Order-Sorted  Algebras:  In  Obj,  the  notion  of  order-sorted  algebras  supports  the 
hierarchical  nature  of  data  types.  Subtypes  (or  subsorts)  can  be  defined  in  a  modular 
fashion.  For  example,  the  ordering  relationship  between  natural  numbers  (i.e.,  Nat) 
and  non-zero  natural  numbers  (i.e.,  NzNat)  is  depicted  by  NzNat  <  Nat.  This 
ordering  relationship  states  that  NzNat  is  a  subset  of  Nat  (Win91). 

2.  Equational  Logic:  The  operations  defined  in  Obj  are  constrained  using  equational 
logic.  Obj  equations  consist  of  two  terms  separated  by  an  equivalence  connective 
(i.e.,  ==).  This  notation  is  useful  for  term  rewriting  to  reduce  an  equation  into  its 
canonical  form.  Rewriting  equations  requires  finding  a  unifier  that  binds  a  variable  to 
its  actual  value.  This  technique  closely  resembles  Lisp’s  “by  value”  method  (GT79). 
When  an  equation  can  no  longer  be  rewritten,  then  the  expression  is  said  to  be 
reduced  or  in  normal  form  (FGJM85). 

3.  Parameterization:  To  enhance  the  modularity  and  extensibility  of  theories,  Obj 
uses  parameterization  to  generalize  specifications  and  make  them  more  reusable. 
For  example,  a  list  object  that  is  algebraically  specified  is  not  tied  to  a  particular 
type  of  element,  but  can  be  parameterized  based  on  the  user’s  design  choice.  Thus, 
parameterization  promotes  class-based  solutions. 
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obj  FIBO  is 

protecting  INT  . 
op  fibo_  :  Int  — >•  Int  . 
var  x:  Int  . 
eq  fibo  x  =  if  x  <  2 
then  X 

else  (fibo  (x  -  1))  +  (fibo  (x  -  2))  fi  . 

endo 

Figure  2.5  Obj  Specification  of  the  Fibonacci  Computation 

4.  Inheritance:  The  main  object  inheritance  mechanism  used  in  Obj  is  centered  around 
three  modes:  protected,  extended,  and  using.  The  protected  mode  is  the  most  re¬ 
strictive  of  the  three  allowing  Obj  modules  to  use  other  modules  in  a  protected  fash¬ 
ion.  That  is,  changes  to  the  inherited  module’s  operations  are  not  allowed  (Win91). 
On  the  other  end  of  the  spectrum  is  the  using  mode  which  allows  Obj  modules  to 
“use”  other  modules  permitting  unrestricted  changes  to  the  inherited  operations. 
This  mode  is  the  loosest  of  the  three  and  does  not  guarantee  correctness-preserving 
behavior  (Win91).  In  the  middle  of  this  spectrum  is  the  extended  mode.  The  ex¬ 
tended  mode  preserves  the  operational  behavior  of  the  inherited  module  but  allows 
developers  to  extend  these  inherited  operations. 

Obj  has  evolved  into  a  high-level  language  used  to  prototype  algebraic  specifications. 
Simulating  a  specification’s  behavior  gives  a  developer  insight  into  the  correctness  and 
coverage  of  his  specification.  An  Obj  specification  defining  the  computation  of  the  n-th 
Fibonacci  number  is  shown  in  Figure  2.5  (Win91). 

2. 3. 2. 2  Larch.  Larch  is  based  on  two  fundamental  principles:  clarity  of 
the  specification  and  concrete  interfaces  between  specified  programs  (GH93).  These  prin- 
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Table:  trait 
includes  Integer 
introduces 
new:  — +  Tab 

add:  Tab,  Ind,  Val  ^  Tab 

6  _ :  Ind,  Tab  Bool 

lookup:  Tab,  Ind  — +  Val 
isEmpty:  Tab  Bool 
size:  Tab  —*  Int 
0,  1;  — +  Int 

_ + _ :  Int,  Int  — +  Int 

asserts  V  i,  il:  Ind,  v:  Val,  t:  Tab 

-1  (i  €  new); 

i  G  add(t,  il,  v)  ==  i  =  il  V  i  G  t; 
lookup(add(t,  i,  v) ,  il)  == 

if  i  =  il  then  v  else  lookup(t,  il); 
size(new)  ==  0; 
size(add(t,  i,  v))  == 

if  i  G  t  then  size(t)  else  size(t)  +  1; 
isEmpty(t)  ==  size(t)  =  0 

Figure  2.6  Table.lsl 

ciples  are  achieved  using  two  separate  representations:  a  shared  language  and  an  interface 
language. 

The  Larch  shared  language  (LSL)  is  a  high-level,  generic  language  that  formally 
describes  the  fundamental  objects,  relationships,  and  properties  in  a  problem  domain. 
The  emphasis  of  the  shared  language  is  to  describe  the  observable  behavior  and  the  basic 
constructs  of  an  object.  Since  LSL  traits  specify  domain-specific  concerns,  these  traits  are 
a  principal  reusable  component  (GH93).  Figure  2.6  depicts  an  LSL  specification  describing 
the  class  of  tables  (GH93). 


While  the  LSL  specification  captures  domain-specific  issues,  the  interface  language 
concentrates  on  a  module’s  interface  and  communication  to  other  modules  at  the  imple¬ 
mentation  level.  Based  on  a  particular  programming  language  such  as  C,  Modula,  or 
Ada,  the  interface  language  handles  implementation  dependencies  such  as  parameter  pass- 
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ing  and  exception  handling.  This  division  of  labor  between  the  Larch  shared  language 
and  the  interface  language  provides  a  smooth  transition  from  a  formally  specified  problem 
description  into  a  formal  implementation. 

2.4  Formal  Object  Transformation  Processes 

Both  object-oriented  methods  and  formal  methods  have  been  praised  as  successful 
techniques  for  specifying  software  systems  (RBP'^91)  (Sri91).  Consequently,  research  has 
begun  to  capitalize  upon  the  successes  of  both  techniques  by  exploring  approaches  to 
integrate  object-oriented  methods  into  a  formal  framework.  These  efforts  are  described  in 
the  subsequent  sections. 

2.4-1  A  Transformation  of  OMT  Models  into  a  Z  Framework.  Hartrum  and 
Bailor  have  developed  a  formal  object  transformation  process  using  Z  as  the  target  model 
(HB94).  They  have  mapped  the  OMT  object,  dynamic,  and  functional  models  into  a 
Z  framework  of  static  and  dynamic  schemas  creating  a  set-theoretic  representation  for 
each  object-oriented  construct  (HB94).  The  following  enumerates  Hartrum  and  Bailor’s 
transformation  process: 

1.  Object  Transformation  Process:  A  Z  static  schema  is  developed  for  each  object  in 
the  object  model.  The  static  schema’s  signature  defines  the  object  attributes  over 
some  set-theoretic  type  (HB94).  In  the  schema’s  predicate,  constraints  are  written 
to  describe  an  object’s  invariant  conditions  on  the  object’s  attributes  and  between 
the  object’s  attributes  (HB94). 
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2.  Dynamic  Transformation  Process:  Z  static  schemas  are  also  developed  to  specify 
the  dynamic  model  with  each  schema  representing  an  instance  of  an  object’s  overall 
state  space.  Each  schema’s  predicate  defines  invariants  that  represents  a  particular 
state’s  variables.  Presently,  a  formal  transformation  does  not  exist  for  translating 
the  entries  in  a  state  transition  table  into  a  Z  representation. 

3.  Functional  Transformation  Process:  Z  dynamic  schemas  are  developed  to  capture 
the  computational  aspect  of  every  functional  model.  In  the  dynamic  schema’s  signa¬ 
ture,  either  an  object’s  A  schema  or  H  schema  is  included.  The  A  schema  is  included 
if  an  object’s  attributes  will  be  modified  during  the  computation  of  an  object’s  out¬ 
put  values  from  input  values.  Otherwise,  the  S  schema  is  used.  The  predicate  of  the 
dynamic  schema  describes  the  actual  computation  for  the  object,  and  it  also  specifies 
the  invariants  that  hold  during  the  computation. 

Based  on  the  examples  provided  in  the  OMT  section,  Figure  2.7  shows  a  Z  static 
schema  for  the  Person  object  class,  and  Figure  2.8  (HB94)  depicts  the  static  schemas  for 
the  Person  dynamic  models.  The  corresponding  state  transition  table  was  illustrated  in 
Table  2.1,  Subsection  2.2.2.  Figure  2.9  (HB94)  shows  a  dynamic  schema  for  calculating  a 
person’s  age.  Additional  information  on  object-orientation  and  Z can  be  found  in  (Wab94). 

2.4-2  An  Object-Oriented  Design  Transformation  into  an  Algebraic  Framework. 
While  Hartrum  and  Bailor  have  created  a  formal  object  framework  using  Z,  Breu  (Bre91) 
formalizes  object-oriented  design  constructs  using  algebraic  methods.  In  Breu’s  research, 
the  data  type  is  the  basic  entity  during  the  design  phase,  and  it  becomes  the  cornerstone 
for  her  formal  transformation  process.  Breu  takes  the  framework  of  classes  and  methods  in 
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_ Person _ 

lastname  :  seqCH AR 
firstname  :  seqCHAR 
middle-initial  :  CHAR 
ssan  :  seqC H AR 
sex  :  SexType 
age  :  Afi 

birthdate  :  DateType 
^ssan  =  9 


Figure  2.7  Static  Schema  for  Person’s  Object  Model. 


Child _ 

p  :  Person 

p.age  <  18 


, _ Adult _ 

p  :  Person 

p.age  >  18 
p.age  <  65 


_ Senior _ 

p  :  Person 

p.age  >  65 


Figure  2.8  Static  Schema  for  Person’s  Dynamic  Model. 
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_ Determine  Age _ 

APerson 

ECalendar 

new-agel :  Afi 

Today sDatel  :  DateType 

Birthdatel  :  DateType 

new—age\  =  Today  sDatel  —  Birthdatel 


Figure  2.9  Dynamic  Schema  for  Calculating  a  Person’s  Age. 

an  object-oriented  design  and  maps  the  framework  into  an  algebraic  specification  scheme 
using  the  notion  of  inheritance,  subtyping,  and  clientship. 

1.  Class  Inheritance:  Breu  relates  the  notion  of  class  inheritance  in  object-oriented 
design  with  the  notion  of  vertical  composition  in  algebraic  specifications  (Bre91). 
Vertical  composition  is  a  step-wise  transformation  process  where  the  more  abstract 
theory  is  at  the  top  of  the  vertical  structure.  As  more  details  are  included  in  a  theory, 
the  abstract  theory  is  refined  into  a  specialized  theory.  For  example,  a  sort  theory  de¬ 
scribes  a  generalized  notion  for  arranging  elements  in  a  sequence.  A  more  specialized 
sort  theory  based  on  exchanging  elements  can  be  specified  using  a  refinement  process 
to  produce  a  shell  sort  theory  (Sri91).  The  shell  sort  theory  becomes  the  child  in  a 
parent-child  theory  association.  Theories  constructed  using  vertical  composition  are 
modular  and  compact,  making  them  flexible  and  manageable  when  specifying  large 
software  systems. 

2.  Subtyping:  Breu  maps  type  inheritance,  i.e.,  subtyping,  in  object-oriented  designs 
into  an  order-sorted  algebraic  structure  (Bre91).  Order-sorted  algebras  are  the  basis 
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class  Set  is 

methods 

insert  (x;  Int)  is  deferred, 
is_empty  return  Bool  is  deferred, 
is_elem  (x;  Int)  return  Bool  is  deferred 
create  empty  is  deferred 

end  class 

Figure  2.10  Object-Oriented  Class  Specification  of  Set 

of  a  subset  relationship  between  elements,  in  this  case  data  types.  Data  refinement 
is  the  goal  for  subtyping,  and  order-sorted  algebras  meet  this  goal. 

3.  Clientship:  The  object-oriented  method  stresses  the  importance  of  determining 
the  data  dependencies  among  objects,  i.e.,  clientship.  Breu  relates  the  persistency 
characteristic  of  clientship  to  the  algebraic  notion  of  horizontal  composition  (Bre91). 
Horizontal  composition  refers  to  the  communication  between  two  objects  at  the  same 
level  in  a  hierarchical  model.  Since  many  objects  are  not  mutually  exclusive  of 
one  another,  modeling  the  correct  communication  between  objects  is  important.  In 
Breu’s  algebraic  framework,  the  “uses”  clause  establishes  the  horizontal  communica¬ 
tion  mechanism  between  algebraic  specifications. 

Inheritance,  subtyping,  and  clientship  form  the  foundation  of  Breu’s  transforma¬ 
tion  process.  Breu  takes  the  object-oriented  class  framework  of  methods  and  performs  an 
algebraic  mapping  into  a  formal  representation.  Figure  2.10  shows  an  object-oriented  spec¬ 
ification  of  the  class  Set.  In  Breu’s  algebraic  transformation  approach,  the  class  methods 
are  mapped  directly  into  algebraic  operations  with  specified  domain  and  co-domain  sorts. 
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class  spec  Set  is 

uses<Int,  Bool> 
inherits<Spec[parameter:  sort]> 
opns 

empty:  ^  Set, 
insert:  (Set,  Int)  ^  Set, 
is_empty:  (Set)  — >  Bool, 
is_elem:  (Set,  Int)  ^  Bool, 
axioms  V  s:  Set,  x,  y:  Int 
is_empty(empty)  =  true, 
is_empty(insert(s,  x))  =  false, 
is_elem(empty,  y)  =  false, 

X  =  y  =>  is_elem(insert(s,  x),  y)  =  true, 

-I  (x  =  y)  is_elem(insert(s,  x),  y)  =  is_elem(s,  y) 
end  class  spec 


Figure  2.11  Algebraic  Specification  of  Set 

Each  operation’s  invariants  are  mathematically  modeled  as  algebraic  axioms.  Figure  2.11 
shows  the  corresponding  algebraic  mapping  of  the  class  Set. 


2.4-3  An  Algebraic  Transformation  of  an  Unmanned  Subway  System.  Hartrum 
and  Bailor’s  OMT  formalization  using  Z and  Breu’s  algebraic  framework  for  object-oriented 
design  classes  are  extensive  efforts  in  formalizing  the  object-oriented  process.  Dauchy, 
Gaudel,  and  Marre  take  a  more  informal  object  transformation  approach  when  algebraically 
specifying  an  unmanned  subway  system. 

Since  Dauchy,  Gaudel,  and  Marre  are  only  concerned  about  describing  the  reactive 
behavior  of  the  subway,  they  use  state  transition  diagrams  to  model  two  subway  software 
modules.  Each  transition  leaving  a  state  is  prioritized  and  described  by  a  set  of  boolean 
conditions.  The  prioritized  boolean  conditions  are  mapped  into  a  set  of  algebraic  equations 
that  describe  the  valid  transitions  for  a  state.  Thus,  each  state  transition  is  represented  as 
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an  algebraic  equation,  and  the  outgoing  state  transitions  for  each  state  are  grouped  into  a 
set  of  algebraic  axioms. 

Although  Dauchy,  Gaudel,  and  Marre’s  approach  demonstrates  that  state  transfor¬ 
mation  information  can  be  formalized,  they  fail  to  describe  how  to  integrate  the  algebraic 
axioms  into  an  algebraic  specification  framework.  Consequently,  Dauchy,  Gaudel,  and 
Marre’s  approach  does  not  provide  a  comprehensive  framework  necessary  for  an  adequate 
object  transformation  process. 

2.5  Summary 

This  literature  review  established  a  detailed  knowledge  base  to  support  the  develop¬ 
ment  of  an  algebraic-based  execution  framework.  First,  to  develop  an  algebraic  transfor¬ 
mation  process,  the  algebraic  target  language  should  support  object-oriented  constructs 
such  as  inheritance,  aggregation,  and  behavioral  constraints.  Second,  to  formally  spec¬ 
ify  OMT  analysis  models,  a  systematic  approach  needs  to  be  developed.  This  approach 
must  preserve  the  object-oriented  properties  of  each  OMT  model  and  the  relationship  be¬ 
tween  the  models.  Finally,  the  feasibility  of  creating  an  execution  framework  for  algebraic 
specifications  is  supported  by  the  advances  achieved  in  using  and  composing  algebraic 
specifications. 
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III.  Evolutionary  Approach  to  the  Formal  Object  Transformation  Process 


3.1  Introduction 

Chapter  I  introduced  the  notion  of  a  formal  object  transformation  process  to  com¬ 
plement  the  current  KBSE  domain  application  composition  system.  To  make  this  idea  a 
reality  requires  establishing  a  development  approach  that  embodies  the  major  tasks  shown 
in  Figure  1.1: 

•  Creating  an  algebraic  framework  for  object-oriented  models 

•  Developing  an  algebraic  language  compiler 

•  Producing  a  unification  model  for  formal  languages 

•  Establishing  an  execution  framework 

Because  each  task  produces  an  incremental  product  that  matures  during  develop¬ 
ment,  the  evolutionary  life-cycle  was  selected  as  the  development  strategy.  An  evolution¬ 
ary  approach  uses  an  iterative  process  for  developing  an  early  operational  capability  of  a 
system  (USA93).  Using  this  iterative  process  makes  the  products  flexible  and  easily  exten¬ 
sible  for  future  requirements.  While  each  iteration  fulfills  a  minimum  set  of  requirements, 
together  they  form  the  ultimate  capability  for  a  system  (USA93). 

From  the  four  tasks,  four  phases  were  defined  for  the  formal  object  transformation 
process: 

1.  An  Algebraic  Transformation  Process 

2.  An  Algebraic  Language  Parser 
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3.  A  Unified  Domain  Model 


4.  An  Execution  Framework 

This  chapter  describes  the  requirements  and  design  for  producing  an  algebraic  framework, 
the  product  of  the  algebraic  transformation  process.  Additionally,  this  chapter  introduces 
the  formal  execution  stage  represented  by  the  last  three  phases. 

3.2  Selecting  the  Algebraic  Framework  Language 

Selecting  a  particular  algebraic  language  provided  a  design  foundation  and  target 
framework  for  the  algebraic  transformation  process.  Since  OMT  models  are  the  source 
for  the  transformation  process,  the  target  algebraic  framework  must  represent  the  object- 
oriented  characteristics  of  inheritance,  aggregation,  state  behavior,  and  the  separation  of 
policy  and  implementation  issues.  In  addition,  demonstrating  a  specification’s  behavior  is 
an  important  factor;  thus,  the  ability  to  execute  an  algebraic  language  is  the  final  criterion. 

Because  of  the  extensive  descriptions  provided  in  Chapter  II  for  Obj  and  Larch, 
these  two  languages  were  selected  for  evaluation.  The  following  compares  and  contrasts 
Obj  and  Larch  based  on  the  object-oriented  criteria  defined  above. 

Obj  and  Larch  are  similar  with  respect  to  modeling  inheritance  and  aggregation 
and  in  providing  a  well-suited  notation  for  execution.  Obj  has  three  modes  of  inheritance, 
protected,  extended,  or  used,  that  can  be  selected  by  the  user  based  on  his  requirements. 
Larch  incorporates  inheritance  using  the  includes  and  renames  facilities.  For  aggregation. 
Larch  uses  the  includes  clause  while  Obj  uses  the  sorts  clause  to  reference  other  traits 
and  sorts,  respectively.  Because  Obj  and  Larch  are  mathematical  languages  based  on 
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provable  constructs,  their  grammars  are  precise  and  well-structured.  This  precision  makes 
it  easy  to  turn  the  languages  into  executable  code  (NS91).  Thus,  both  languages  are 
well-suited  for  compilation  and  execution. 

The  major  difference  between  the  two  languages  is  the  syntactical  structure  of  the 
specification.  Obj  is  a  single-structure  specification  language  that  focuses  on  describing 
and  executing  non-deterministic  behavior.  Larch’s  two-tiered  approach  makes  it  a  more 
comprehensive  specification  language  because  the  approach  separates  the  issues  of  policy 
from  implementation.  Therefore,  the  two-tiered  method  allows  specifiers  to  transition 
from  an  algebraically-based  specification  into  an  algebraically-based  implementation.  This 
transition  mechanism  simplifies  the  specification  of  reactive  systems  by  capturing  abstract 
behavior  in  the  shared  language  while  specifying  the  explicit  pre-  and  postconditions  in 
the  interface  language. 

Another  advantage  of  Larch  is  the  availability  of  automated  support  tools.  The 
creators  of  Larch  developed  a  suite  of  tools  to  check  LSL  specifications  and  to  reason 
about  LSL  specifications.  The  wider  support  environment  and  the  two-tiered  approach 
were  the  reasons  for  selecting  Larch  as  the  target  language. 

S.3  The  Algebraic  Transformation  Phase 

Correlating  the  OMT  models  described  in  Chapter  II  to  the  target  framework,  the 
Larch  shared  language,  required  three,  separate  algebraic  transformation  processes:  ob¬ 
ject,  dynamic,  and  functional  transformations.  The  design  for  each  transformation  process 
rested  on  one  principle:  preserving  the  object-oriented  constructs  found  in  each  model. 
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Figure  3.1  Algebraic  Transformation  Phase 


Figure  3.1  illustrates  the  three  algebraic  transformation  processes,  and  the  following  sub¬ 
sections  outline  the  steps  required  for  each  transformation. 


S.3.1  Object  Model  Transformation.  An  OMT  object  model  captures  the  im¬ 
portant  objects,  object  attributes,  and  relationships  between  objects  in  a  software  system 
(RBP+91).  Its  goal  is  system  comprehension,  and  any  algebraic  representation  of  the  ob¬ 
ject  model  must  preserve  this  goal.  Therefore,  the  object-oriented  characteristics  of  object 
attributes,  attribute  invariants,  inheritance,  and  aggregation  form  the  framework  for  the 
Larch  object  theory. 
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Person:  trait 
includes  Integer 
introduces 

N,  SN,  A  P 

_ .name:  P  — »■  N 

_ .ssan:  P  — >  SN 

_ .age:  P  — »  A 

set_name:  P,  N  ^  P 
set_ssan:  P,  SN  — P 
set_age:  P,  A  — v  P 
size:  SN  ^  Int 

asserts  V  n,  nl:  N,  sn,  snl :  SN,  a,  al:  A,  p:  P 
size(p.ssan)  ==  9; 

([n,  sn,  a]). name  ==  n; 

([n,  sn,  a]). ssan  ==  sn; 

(Cn,  sn,  a]). age  ==  a; 

set_name([n,  sn,  a],  nl)  ==  [nl,  sn,  a]; 
set_ssan(Cn,  sn,  a],  snl)  ==  [n,  snl,  a]; 
set_age([n,  sn,  a],  al)  ==  [n,  sn,  al] 

Figure  3.2  Attributes  Transformed  into  Algebraic  Operators 

Transforming  the  object  classes  into  a  Larch  object  theory  framework  requires  the 
following  steps; 


1.  Create  an  LSL  trait  for  each  object  class. 

2.  Transform  each  object’s  attribute  in  one  of  two  ways: 


•  Create  an  LSL  operator  for  each  object  attribute.  For  each  operator,  define  the 
appropriate  signature  specifying  the  attribute’s  domain  and  range.  Figure  3.2 
depicts  this  alternative  using  the  Person  class. 

•  Create  an  LSL  sort  representing  the  trait  and  use  the  tuple  notation.  Each 
tuple  field  represents  an  attribute  of  the  object.  This  alternative  is  illustrated 
in  Figure  3.3. 
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Person:  trait 
includes  Integer 

P  tuple  of  name:  N,  ssan:  SN,  age:  A 
introduces 

size:  SN  Int 

asserts  V  p:  P,  n:  N,  sn:  SN,  a:  A 
size(p.ssan)  ==  9; 
p.name  ==  n; 
p.ssan  ==  sn; 
p.age  ==  a; 

Figure  3.3  Attributes  Transformed  into  an  Algebraic  Tuple  Notation 

3.  Because  derived  attributes  are  computed  from  static  attributes,  Larch’s  operator 
notation  best  captures  derived  attributes.  Therefore,  for  every  derived  attribute, 
create  an  LSL  operator  with  the  appropriate  signature. 

4.  Use  axiomatic  equations  to  define  constraints  on  attributes  and  between  an  object’s 
attributes.  Also,  use  algebraic  equations  to  specify  an  operator’s  behavioral  con¬ 
straints. 

5.  Analyze  the  inheritance  and  aggregation  properties  of  the  object  model.  For  each 
object  that  inherits  from  its  parent,  include  the  associated  parent  trait  in  the  LSL  in¬ 
cludes  clause.  To  specialize  a  parent  trait’s  parameter  values,  rename  the  parameters 
using  Larch’s  rename  notation.  For  each  object  that  uses  another  object,  provide 
the  used  object  trait  in  the  LSL  includes  clause. 

6.  Reserve  multiple  inheritance  for  future  efforts.  Although,  multiple  inheritance  is  an 
important  feature  in  object-oriented  models,  it  increases  the  complexity  of  algebraic 
specifications.  Therefore,  the  initial  design  of  the  algebraic  object  theory  includes 
only  single  inheritance. 
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Person 


name:  String 
ssan:  String 
age:  Natural 
dead:  Boolean 


caiculate_age(bdate,  tdate):  Natural 


Figure  3.4  Person  Object  Model 


Person:  trait 
includes  Integer 

P  tuple  of  name:  N,  ssan;  SN,  age:  A 
introduces 

size:  SN  — *■  Int 

asserts  V  p:  P,  n:  N,  sn:  SN,  a:  A 
size(p.ssan)  ==  9; 
p.name  ==  n; 
p.ssan  ==  sn; 
p.age  ==  a; 

Figure  3.5  Person  Object  Trait 

To  illustrate  the  object  transformation  process,  Figure  3.4  shows  an  object  model  for 
a  Person  class,  and  Figure  3.5  represents  its  formal  framework. 


3.3.2  Dynamic  Model  Transformation.  The  most  challenging  of  the  three  trans¬ 
formation  processes  is  the  dynamic  model  transformation.  The  OMT  dynamic  model 
describes  the  reactive  behavior  of  an  object  using  states  and  events.  Therefore,  the  dy¬ 
namic  transformation  process  must  preserve  two  important  characteristics:  an  object’s 
state  space  and  an  object’s  state  transition  information  (i.e.,  events,  current  state,  and 
next  state). 
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To  use  the  LSL  traits  as  a  framework  for  the  OMT  dynamic  model  required  evaluating 
two  different  approaches;  Dauchy,  Gaudel,  and  Marre’s  approach  and  the  Mealy  Machine 
approach.  The  criteria  for  evaluation  was  to  select  an  alternative  that  mapped  best  to  the 
OMT  dynamic  model  and  to  the  LSL  trait  characteristics. 

Dauchy,  Gaudel,  and  Marre  demonstrate  one  alternative  for  formally  modeling  state 
transitions  in  their  subway  system  example.  They  use  boolean  expressions  to  model  each 
state  transition,  prioritizing  each  state’s  boolean  expressions  to  form  a  set  of  axioms.  Even 
though  their  approach  transforms  the  state  transitions  into  a  set  of  algebraic  axioms,  they 
fail  to  integrate  these  axioms  into  a  coherent  algebraic  theory. 

The  Mealy  Machine  model  provides  a  second  alternative.  It  associates  each  output 
of  a  state  with  a  state  transition.  In  relation  to  the  OMT  dynamic  model,  this  corresponds 
to  associating  each  output  of  a  state  with  an  activity.  That  is,  the  input  to  an  activity 
would  be  a  state  of  an  object  and  the  activity’s  output  determines  the  next  state  of  an  ob¬ 
ject.  Formally  modeling  the  states  and  activities  is  possible  within  the  Larch  framework. 
Therefore,  the  Mealy  model  fits  in  well  with  the  OMT  models  and  the  Larch  algebraic 
structure. 

The  following  steps  describe  the  dynamic  transformation  process  using  the  Mealy 
Machine  approach: 

•  Larch  Framework  for  States: 

1.  Transform  each  state  in  a  dynamic  model  into  a  separate  Larch  trait  that  in¬ 
cludes  the  object  class  trait. 
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2.  For  each  state  trait,  define  a  valid-state  boolean  operator.  The  operator’s  signa¬ 
ture  defines  the  object  as  the  domain  and  a  boolean  as  the  range.  The  operator 
determines  whether  or  not  an  object  is  within  a  particular  state. 

3.  Analyze  each  valid-state  operator  and  define  appropriate  behavioral  constraints 
in  the  LSL  asserts  clause.  The  constraints  represent  the  valid  attribute  ranges 
for  a  state  and  are  in  the  form  of  axiomatic  equations. 

•  Larch  Framework  for  Events: 

1.  For  each  event  in  the  dynamic  model,  define  an  event  trait.  In  each  event  trait, 
use  boolean  operators  to  specify  the  event. 

2.  Analyze  each  event  operator  and  define  appropriate  constraints  in  the  LSL  as¬ 
serts  clause. 

3.  Reserve  the  activities  associated  with  events  for  the  functional  transformation 
process. 

•  Larch  Framework  for  State  Transition  Tables:  An  object’s  state  transition  table 
identifies  an  object’s  event  sequencing  by  documenting  the  object’s  current  state, 
external  event,  and  next  state  relationship.  Specifying  these  two  subspaces  (i.e.,  the 
current  and  next  states)  in  an  algebraic  equation  violates  the  consistency  property. 
For  example,  the  equation: 

child(P)  A  birthday{age  =  17)  =>  adult{P) 

specifies  when  a  Person  object  “P”  transitions  from  a  child  state  into  an  adult  state. 
This  equation  is  inconsistent  because  the  implication  states  that  a  Person  can  be  in 
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Birthday  [age  <  17]  Birthday  [age  <  64]  Birthday 


Figure  3.6  Person’s  Age  Dynamic  Model 


two  different  states  at  one  time  (i.e.,  in  the  child  and  adult  state  simultaneously). 
This  inconsistent  equation  cannot  be  incorporated  into  an  LSL  specification.  Thus, 
the  most  effective  way  to  specify  an  object’s  event  sequencing  is  to  retain  Rumbaugh’s 
state  transition  table  notation  for  each  object  class.  To  complete  the  dynamic  trans¬ 
formation  process,  create  a  State  Transition  Table  (STT)  for  each  dynamic  model 
and  include  it  with  the  dynamic  theories. 

The  following  figures  demonstrate  a  complete  dynamic  transformation  process  for 
the  Person  class.  Figure  3.6  shows  a  dynamic  model  of  a  Person’s  age  states.  Figure  3.7 
shows  the  corresponding  Larch  state  traits,  Figure  3.8  specifies  the  Larch  event  trait, 
and  Table  3.1  defines  the  state  transition  table. 

S.3.S  Functional  Model  Transformation.  An  OMT  functional  model  describes  an 
object’s  data  transformations,  i.e.,  a  collection  of  data  and  operations  on  the  data,  which 
is  equivalent  to  an  abstract  data  type.  Thus,  encapsulating  a  functional  model  in  a  Larch 
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ChildState:  trait 
includes  Person 
introduces 

child:  P  — *■  Bool 
asserts  V  p:  P 

child(p)  ==  p.age  <  17; 

AdultState;  trait 
includes  Person 
introduces 

adult:  P  — Bool 
asserts  V  p:  P 

adult (p)  ==  p.age  <  64  &  p.age  >  17; 

SeniorState:  trait 
includes  Person 
introduces 

senior:  P  — +  Bool 
asserts  V  p:  P 

senior(p)  ==  p.age  >  64; 

Figure  3.7  Person  State  Traits 


Birthday:  trait 

includes  Person,  Calendar 

introduces 

birthday:  P,  C  — *■  Bool 
asserts  V  p:  P,  c:  C 

birthdayCp,  c)  ==  p.bdate  =  c.tdate; 

Figure  3.8  Person  Event  Trait 
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Table  3.1  Person  State  Transition  Table. 


Current  State 

Event 

Parameters 

Guard 

Next  State 

Action 

m 

Birthday 

Birthday 

death 

HI 

Birthday 

Birthday 

death 

age  <  64 
age  =  64 

Adult 

Senior 

Terminated 

Birthday 

death 

Senior 

Terminated 

specification  is  straightforward.  Defined  below  are  the  three  steps  for  the  transformation 
process; 


1.  Map  each  data  transformation  into  a  separate  Larch  trait.  Include  the  object  trait. 

2.  Define  an  LSL  operator  that  models  the  transform  process.  Model  the  inputs  and 
output  of  the  transform  function  in  the  operator’s  signature. 

3.  Model  the  behavioral  constraints  associated  with  the  transform  as  LSL  algebraic 
equations. 

To  complete  the  Person  class  example,  Figure  3.9  shows  a  functional  model  for  calcu¬ 
lating  a  person’s  age,  and  the  corresponding  Larch  functional  theory  is  depicted  in  Figure 
3.10. 


3.3.4  Validation.  To  effectively  demonstrate  the  algebraic  transformation  pro¬ 
cess,  two  validation  domains  were  selected:  the  counter  and  fuel  tank  domains.  The  counter 
domain  represents  a  simple  non-reactive  system  used  to  test  the  initial  design  concepts  of 
the  object  and  functional  transformations.  The  fuel  tank  domain  is  a  small-scale  reac- 
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Figure  3.9  Functional  Model  for  Computing  a  Person’s  Age 

CalculateAge:  trait 
includes  Person,  Calendar 
introduces 

NewAge:  C,  P  — *■  Int 
asserts  V  p:  P,  c:  C 

NenAgeCc,  p)  ==  [p.naune,  p.ssan,  c.tdate  -  p.bdate,  p.bdate] 
Figure  3.10  Functional  Trait  for  Computing  a  Person’s  Age 

tive  system  that  provides  a  more  rigorous  exercise  of  the  entire  algebraic  transformation 
process.  This  domain  contains  a  complete  set  of  object,  dynamic,  and  functional  models 
developed  and  refined  by  Hartrum  and  Bailor  (HB94).  The  validation  criteria  levied  on 
both  domains  centered  around  two  principles: 

1.  Coverage  -  The  portion  of  OMT  Analysis  Models  successfully  formalized. 

2.  Consistency  -  An  object’s  behavioral  constraints  do  not  contain  contradictions  (i.e., 
true  =  false). 

The  following  subsections  describe  each  domain’s  adherence  to  these  principles. 

3.3.4- 1  Counter  Domain.  The  counter  domain  contains  a  counter  object 
class  and  three  data  transformations:  increment,  add,  and  subtract,  depicted  in  Figure 
3.11.  Thus,  each  of  these  constructs  must  be  formally  modeled  and  validated.  The  following 
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OBJECT  MODEL 


Counter 


value:  Integer 
limit:  Integer 


FUNCTIONAL  MODELS 


Counter 


Figure  3.11  Counter  Domain’s  OMT  Models 
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describes  the  validation  process: 


1.  Formal  Framework  Development:  A  formal  framework  was  established  for  the 
counter  domain  consisting  of  four  traits:  an  object  trait  and  three  functional  traits. 
The  object  trait  represents  the  counter  object  class  capturing  the  object  attributes  in 
a  tuple  notation  and  specifying  the  invariants  between  the  attributes  using  axiomatic 
equations.  Each  functional  trait  models  a  transform  function  as  an  abstract  opera¬ 
tor  and  uses  axiomatic  equations  to  represent  the  behavioral  constraints.  Therefore, 
the  entire  domain  was  formally  modeled,  conforming  to  the  coverage  criteria.  This 
formal  framework  is  found  in  Appendix  A. 

2.  Domain  Theory  Evaluation:  The  traits  were  evaluated  against  the  original  domain 
model  to  ascertain  its  consistency  with  the  model’s  object  structure,  operations,  and 
invariants.  This  evaluation  demonstrated  that  the  domain  theory  precisely  identified 
the  important  properties  and  behavioral  constraints  in  the  counter  domain. 

3. 3. 4-2  Fuel  Tank  Domain.  The  fuel  tank  domain  consists  of  an  object  class 
with  several  attributes  and  a  set  of  four  states  and  events.  Because  there  are  numerous 
functional  transformations  in  the  domain,  three  were  selected  as  a  subset  for  validation 
purposes:  Determine  Interval,  Calculate  Filled  Level,  and  Predict  Tank  Full  Time.  Ap¬ 
pendix  B  contains  the  OMT  models  and  state  transition  table  for  the  Fuel  Tank  Domain. 
The  following  enumerates  the  validation  results: 

1.  Formal  Framework  Development:  Analogous  to  the  counter  domain’s  validation  pro¬ 
cess,  a  formal  framework  was  established  for  the  fuel  tank  object  class  and  transform 
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functions  using  the  same  tuple  notations  and  operator  constructs.  Therefore,  the 
object  and  functional  transformation  processes  conformed  to  the  coverage  criteria. 
Coverage  for  the  dynamic  model  transformation  was  defined  as  formally  specifying 
the  states  and  events  with  their  invariants,  and  the  dynamic  transformation  process 
fulfilled  this  objective.  The  formal  specifications  for  the  Fuel  Tank  Domain  can  be 
found  in  Appendix  C.  In  addition,  Appendix  D  contains  a  Refine  object-based 
description  for  the  state  transition  tables.  This  specification  parses  the  Fuel  Tank’s 
state  transition  table  creating  objects  for  the  execution  framework. 

2.  Domain  Theory  Evaluation:  The  Larch  framework  provided  a  precise  description 
of  the  fuel  tank  domain  by  capturing  the  domain’s  essential  properties  and  behavior. 
Each  property  could  be  checked  systematically  because  of  the  specification’s  precise 
notation.  Thus,  this  transformation  validated  the  consistency  criteria. 

S.3.5  Summary.  This  section  described  the  algebraic  transformation  process  and 
presented  the  validation  criteria.  Validating  the  transformation  process  proved  extremely 
beneficial  for  testing  the  coverage  and  consistency  of  the  transformation  process.  Satisfying 
these  two  criteria  demonstrated  that  the  OMT  models  could  be  formally  transformed  into 
an  algebraic  framework  without  loss  of  information  (i.e.,  the  structural  and  behavioral 
properties  were  preserved).  The  operational  products  from  this  phase  consist  of  a  set  of 
Larch  traits  representing  a  domain  theory.  The  next  phase  uses  these  domain  theories  as 
input  for  generating  an  initial  execution  framework  for  formal  specifications. 
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Figure  3.12  Analysis-Synthesis  Model 


3.4  The  Formal  Execution  Phase 


The  formal  execution  phase  is  responsible  for  translating  the  Larch  specifications 
into  executable  programs.  Figure  3.12  depicts  two  distinct  stages  in  creating  a  compiler: 
analysis  and  synthesis  of  the  source  language  (ASU88).  For  the  formal  object  transfor¬ 
mation  process,  the  compilation  process  is  extensive;  therefore,  three  chapters  have  been 
devoted  for  describing  the  details  of  each  compilation  evolution.  Chapter  IV  describes  the 
design  and  development  of  a  Larch  parser.  Chapter  V  presents  a  unified  approach  for 
developing  Larch  and  Z  language  parsers.  Finally,  Chapter  VI  contains  a  design  for  an 
execution  framework. 


3.5  Summary 

This  chapter  established  a  basis  for  using  an  evolutionary  development  approach, 
evaluated  two  algebraic  language  representations,  and  enumerated  the  steps  for  an  algebraic 
transformation  process  between  OMT  models  and  Larch  traits.  An  evolutionary  approach 
was  selected  because  of  the  iterative  nature  of  developing  a  formal  transformation  process. 
The  first  iteration  required  selecting  an  algebraic  target  language  to  support  the  design 
of  an  algebraic  transformation  process.  Larch  was  selected  because  of  its  two-tiered 
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specification  approach  and  available  support  environment.  The  algebraic  transformation 
process  specified  a  set  of  steps  required  to  transform  the  OMT  models  into  a  Larch 
framework  of  traits.  Based  on  preserving  the  object-oriented  characteristics  in  the  OMT 
models,  each  step  ascertained  the  resulting  domain  theory’s  consistency  with  the  domain 
model.  Consistency  and  coverage  were  the  two  validation  criteria  used  to  validate  the 
transformation  process.  The  next  phase  uses  the  validated  domain  theories  as  input  for 
producing  a  robust  Larch  parser,  the  first  step  towards  developing  a  formal  execution 
framework. 
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IV.  Design  and  Implementation  of  a  LaRCH  Parser 
4.1  Introduction 

After  establishing  Larch  as  our  algebraic  framework,  the  next  step  focused  on  de¬ 
veloping  a  robust  Larch  parser.  Language  parsing,  depicted  in  Figure  4.1,  combines 
the  lexical  and  syntactical  analysis  processes  together  to  generate  a  syntax  tree.  First, 
the  lexical  analysis  phase  scans  a  source  program  and  groups  the  characters  into  a  set  of 
meaningful  tokens.  Then,  the  syntactical  analysis  process  combines  the  tokens  to  create 
a  program’s  syntactic  hierarchy.  A  well-designed  parser  simplifies  the  semantic  analysis 
tasks  leading  to  a  more  robust  intermediate  representation  for  code  generation  (ASU88). 

This  chapter  presents  two  iterations  in  the  design  and  implementation  of  a  Larch 
parser.  It  describes  the  parsing  environment,  outlines  the  requirements  for  the  parser, 
and  discusses  the  design  decisions  and  trade-offs.  In  addition,  the  validation  results  are 
presented. 
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Figure  4.1  Compilation  Analysis  Phase 


^.2  Software  Refinery  -  The  Parsing  Environment 


Developing  a  language  parser  requires  a  stable  development  environment.  Soft¬ 
ware  Refinery  was  selected  because  it  offers  a  complete  programming  environment  to 
support  not  only  language  parsing  but  also  code  generation.  The  following  lists  some  of 
the  strengths  of  the  SOFTWARE  Refinery  environment  (Rea): 

•  It  provides  capabilities  to  formalize  specifications  and  to  generate  executable  pro¬ 
grams  from  these  specifications. 

•  It  supports  a  wide  range  of  specification  techniques  from  implicit  transformations  to 
explicit  programming  constructs  like  if-then-else. 

•  It  is  an  object-based  environment  that  allows  specifiers  to  query  and  manipulate 
objects. 

•  It  contains  a  powerful  toolset  that  supports  language  parsing. 

Because  this  chapter  emphasizes  parsing,  we  concentrate  on  Software  Refinery’s  pars¬ 
ing  toolset:  Dialect  and  Object  Inspector. 

Dialect  allows  one  to  construct  a  formal  language  syntax  using  the  notion  of  object 
classes  and  map  attributes  in  an  extended  Backus  Naur  Form  (BNF)  notation.  The  object 
classes  represent  the  unique  non-terminals  on  the  left-hand  side  of  a  language’s  grammar 
rules,  and  the  map  attributes  form  the  corresponding  right-hand  side.  These  object  classes 
and  attributes  define  the  domain  model  for  a  language  in  Refine’s  object  base.  Once  a 
grammar  and  domain  model  are  constructed.  Dialect  can  parse  source  programs,  storing 
them  in  the  object  base  as  abstract  syntax  trees  (ASTs)  (And92).  These  ASTs  can  be 
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viewed  using  OBJECT  Inspector.,  a  graphical  interface  tool,  that  allows  one  to  discern 
the  underlying  structure  of  a  source  program. 

4-3  Larch  Parser  -  Part  P 

There  was  one  fundamental  goal  for  developing  a  Larch  parser  -  to  represent  and 
parse  the  complete  language.  Meeting  this  objective  required  developing  a  stable  domain 
model  and  grammar  in  Refine’s  object  base.  The  original  Larch  grammar,  developed 
at  MIT,  was  the  primary  reference  for  identifying  the  core  objects  and  associations. 

4-3.1  Domain  Analysis.  Larch’s  modular  structure  makes  a  top-down  decom¬ 
position  of  the  grammar  rules  into  object  classes  and  map  attributes  a  suitable  approach. 
The  following  summarizes  the  main  object  classes  in  Larch  and  Figure  4.2  graphically 
depicts  the  top-down  decomposition. 

1.  Trait  Name:  Identifies  the  specification. 

2.  Trait  Parameters:  Sorts  used  as  parameters  that  generalize  a  specification,  making 
them  reusable.  For  example,  a  list  specification  can  generically  designate  a  sort  E 
to  represent  any  valid  element  type.  Then,  this  sort  can  be  specialized  based  on  a 
user’s  requirements  (e.g.,  renaming  E  to  Integer). 

3.  Trait  Body: , 

•  Context  References: 

^The  original  Larch  domain  model  and  grammar  described  in  the  following  section  are  not  included  in 
this  document.  The  final  versions  are  presented  in  Chapter  V,  the  unification  phase. 
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Figure  4.2  Main  Object  Classes  in  Larch 


-  External  References:  Allows  a  specification  to  reference  another  specifica¬ 
tion  using  an  includes  or  an  assumes  association. 

-  Shorthand  Notations:  Compact  notations  used  to  shorten  and  simplify 
a  Larch  specification.  They  include  tuples,  enumerations,  and  unions 
(GH93). 

•  Operators:  Represent  total  functions  that  define  a  specification’s  abstract  op¬ 
erations.  Each  function  contains  a  signature  denoting  its  domain  and  range 
sorts  (GH93). 

•  Axioms:  Algebraic  equations  used  to  define  the  behavior  of  operators  and 
relationship  between  operators. 

•  Consequences:  Specify  redundant  algebraic  equations  that  provide  checkable 
properties  (i.e.,  consistency,  completeness,  and  correctness). 
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4.3.2  Parser  Validation.  After  defining  the  entire  grammar  in  the  object  base, 
two  domains  were  selected  for  validation:  a  sample  set  of  traits  developed  at  MIT^  and  the 
counter  domain.  The  MIT  traits  were  selected  because  they  have  been  rigorously  examined 
by  the  Larch  developers.  In  addition,  these  traits  covered  a  myriad  of  Larch  language 
features  and  exercised  many  of  the  capabilities  needed  in  the  parser.  The  counter  domain 
was  selected  because  it  continued  the  domain  validation  process  initiated  in  Chapter  III. 

Both  test  domains  were  evaluated  using  three  criteria:  coverage,  consistency,  and 
correctness  (Wab94).  To  adhere  to  these  criteria,  two  test  cases  were  established. 

1.  Test  Case  1  -  Grammar  Validation:  This  test  is  responsible  for  identifying  and 
resolving  the  ambiguity  in  the  grammar  during  compilation.  The  parser  reports 
these  conflicts  as  either  shift/reduce  or  reduce/reduce  errors.  That  is,  a  shift/reduce 
conflict  occurs  when  the  parser  does  not  know  whether  to  shift  a  new  token  onto 
the  current  sentence,  or  reduce  the  tokens  into  a  sentence.  On  the  other  hand,  a 
reduce/reduce  error  happens  when  the  parser  has  two  reduction  choices. 

In  our  case,  ambiguity  occurred  while  compiling  the  theorem  proving  equations  be¬ 
cause  the  equation’s  production  rules  matched  the  rules  for  the  axiomatic  equations. 
An  analysis  of  the  debug  file  failed  to  identify  a  solution  to  these  errors.  Therefore, 
to  produce  a  rapid  prototype  of  the  parser,  the  theorem  proving  clauses  were  omitted 
since  they  only  added  redundancy  checking.  Removing  these  clauses  resulted  in  less 
than  100%  coverage  of  the  language. 

^The  Massachusetts  Institute  of  Technology  (MIT)  has  a  public  domain  Larch  site  that  contains  a 
compendium  of  Larch  information,  including  a  collection  of  Larch  traits.  This  site  can  be  accessed 
through  world-wide  web,  http://larch-www.lcs.mit.edu:8001/larch/ 
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2.  Test  Case  2  -  Parser  Evaluation:  Parser  evaluation  consisted  of  analyzing  the  ab¬ 
stract  syntax  trees  against  the  grammar’s  syntactic  rules  to  demonstrate  consistency 
and  correctness.  During  the  first  pass,  we  discovered  the  ASTs  violated  the  gram¬ 
mar’s  syntax.  This  occurred  because  the  parser  did  not  enforce  the  proper  selection 
when  encountering  an  or  (rule  choice)  notation  in  the  production  rules.  Correct¬ 
ing  this  error  resulted  in  a  parser  that  was  correct  and  consistent  with  the  original 
grammar’s  syntax  rules. 

4-3.3  Summary.  Although  the  traits  parsed  successfully,  Object  Inspector 
showed  that  the  ASTs  contained  several  recursive  layers  making  the  ASTs  difficult  to 
understand.  At  times.  Object  Inspector  could  not  bring  up  the  entire  AST  because 
of  the  AST’s  unwieldy  structure.  Consequently,  instead  of  providing  the  desired  concise 
description  of  Larch’s  syntax,  the  ASTs  were  too  complex. 

4-4  Larch  Parser  -  Part  IP 

The  prototyped  parser  defined  in  Section  4.3  generated  ambiguous  ASTs  and  proved 
to  be  an  inadequate  parser  because  it  did  not  satisfy  the  coverage  criteria.  Specifically, 
Larch’s  grammar  rules  for  defining  algebraic  equations  were  too  abstract.  In  addition, 
the  complete  Larch  language  was  not  implemented  due  to  the  ambiguity  of  the  theorem 
proving  clauses.  Overcoming  these  deficiencies  required  a  second  iteration  of  the  parser. 
This  iteration  established  two  goals:  to  parse  the  entire  Larch  language  and  to  generate 

®Again,  because  of  the  evolutionary  development  approach,  the  original  model  and  grammar  are  not 
documented.  The  final  versions  are  presented  in  the  next  chapter. 
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well-defined  ASTs.  In  order  to  generate  precise  ASTs,  a  domain  analysis  was  required  to 
identify  the  areas  of  abstraction. 

4-4-i  Domain  Analysis.  A  new  domain  model  for  the  Larch  language  was 
constructed  beginning  with  the  object  classes  defined  in  Subsection  4.3.1  and  shown  in 
Figure  4.2.  The  original  grammar  contained  several  recursive  hierarchies  because  the 
Larch  developers  wanted  to  provide  an  abstract  description  of  the  language  emphasizing 
brevity  rather  than  executability,  but,  we  required  a  more  concrete  syntax  to  implement 
the  grammar.  Therefore,  two  new  sub-hierarchies  were  defined  to  make  the  grammar  more 
explicit:  an  algebraic  equations  and  a  consequences  equations  hierarchy. 

4.4- DI  An  Algebraic  Hierarchy.  The  original  grammar  represented  alge¬ 
braic  equations  in  an  abstract  manner.  Figure  4.3  illustrates  the  definition  of  the  addition 
expression  “argfl  -|-  arg2".  This  figure  clearly  depicts  the  recursive  nature  of  the  grammar 
and  the  onerous  AST  representation. 

To  reduce  the  amount  of  recursion,  each  abstract  expression  was  decomposed  into  in¬ 
dividual  expression  types.  That  is,  the  domain  model  represented  each  algebraic  expression 
(e.g.,  add,  subtract,  and  multiply)  as  individual  objects  (i.e.,  subclasses)  of  the  algebraic 
expression  class.  This  concrete  definition  generated  a  wider  AST  structure  but  reduced 
the  AST’s  depth  and  complexity.  Figure  4.4  demonstrates  a  more  precise  representation 
of  the  add  expression  described  above. 

4.4- 1-2  A  Theorem  Proving  Hierarchy.  Recursion  in  the  theorem  proving 
clauses  caused  similar  ambiguity  errors  in  the  initial  parser.  The  ambiguity  occurred  be- 
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Figure  4.3  Recursive  Nature  of  Larch 


cause  the  Larch  theorem  proving  definition  contains  a  choice  between  two  similar  rules: 
one  that  contains  an  equations  formulation  and  another  that  contains  a  quantified  equa¬ 
tions  formulation.  The  similarities  and  recursive  nature  of  these  rules  confused  the  parser, 
making  the  parser  unable  to  resolve  the  ambiguity.  To  solve  this  problem,  two  separate 
object  classes  were  defined  to  represent  each  choice.  This  approach  eliminated  one  level  of 
recursion,  clarified  the  parsing  choices,  and  simplified  the  corresponding  AST  structure. 


Figure  4.4  Concrete  Definition  of  an  Algebraic  Expression 
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4-4-1-3  Domain  Model  Summary.  The  completed  object-oriented  domain 
model  proved  to  be  an  ideal  map  into  Refine’s  object  base.  The  objects  and  associations 
mapped  directly  into  object  classes  and  map  attributes  forming  the  class  hierarchy  and 
surface  syntcix  for  the  Larch  parser.  After  defining  the  domain  model  and  grammar  in 
Refine,  the  parser  was  ready  for  evaluation. 

4.4-2  Parser  Validation.  This  validation  process  paralleled  the  first  one  using  the 
same  test  sets,  validation  criteria,  and  test  cases.  The  results  obtained  from  the  validation 
process  are  listed  below. 

1.  Case  1  -  Grammar  Validation:  During  compilation,  DIALECT  reported  one  re¬ 
duce/reduce  error.  This  error  occurred  in  the  Larch  consequences  section.  Since 
only  one  error  occurred,  analyzing  this  problem  was  reserved  for  the  parser  evaluation 
phase  to  determine  the  severity  of  the  error. 

2.  Case  2  -  Parser  Evaluation:  This  evaluation  revealed  that  the  grammar  omitted 
several  algebraic  expressions;  some  of  them  are  depicted  in  Figure  4.5.  This  occurred 
because  of  the  explicit  nature  of  defining  algebraic  expressions.  Although  the  terms 
were  initially  omitted,  adding  these  expressions  was  straightforward  because  of  the 
well-structured  domain  model  and  grammar  designed  in  Section  4.4.1.  After  adding 
the  undefined  expressions,  the  single  reduce/reduce  error  was  evaluated.  A  visual 
inspection  showed  that  the  ASTs  matched  the  original  grammar’s  syntactic  structure; 
thus,  the  single  reduce/reduce  error  did  not  adversely  impact  the  parser. 
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asserts  V  a:  A,  1,  11,  12:  C 

flatten ((atom (a)  Hi))  ==  atom(a)  H  flatten(l) ; 
flatten((list(ll)  H  12))  == 
flatten(ll)  ||  flatten(12) ; 
reverseAlK (atom(a)  Hi))  == 
reverseAll(l)  h  atom(a) ; 
reverseAlK (list(ll)  H  12))  == 

reverseAll(12)  h  list(reverseAll(ll) ) ; 

Figure  4.5  Example  of  Undefined  Axiomatic  Terms 

4-4-3  Summary.  The  end  of  the  second  parser  evaluation  satisfied  all  three 
validation  criteria: 

1.  Coverage:  Generating  a  parser  for  the  complete  language 

2.  Consistency:  Remaining  consistent  with  the  grammar’s  syntax 

3.  Correctness:  Producing  syntactically  correct  ASTs 

4-5  Summary 

The  goal  to  develop  a  robust  Larch  parser  was  achieved  during  this  evolution. 
Reaching  this  goal  required  redefining  several  ambiguous  language  expressions  to  generate 
well-structured  ASTs.  An  unambiguous  AST  simplifies  the  remaining  compilation  process 
by  providing  a  stable  framework  for  performing  semantic  analysis  tasks  and  code  gener¬ 
ation.  In  addition,  a  robust  Larch  parser  establishes  a  strong  foundation  for  the  next 
phase,  developing  a  unifying  abstract  framework  for  formal  languages. 
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V.  Design  and  Implementation  of  a  Unified  Domain  Modef 


5. 1  Introduction 

In  Chapter  I,  two  complementary  paths,  a  set-theoretic,  or  model-based  approach 
and  an  algebraic,  or  theory-based  approach,  were  presented  for  formalizing  object  transfor¬ 
mations  into  the  Refine  object  base.  Figure  5.1  depicts  this  transformation  process  and 
also  shows  a  third  horizontal  path.  This  path  represents  another  transformation  mech¬ 
anism,  one  intended  to  produce  a  unified  model  of  the  designated  formal  specification 
languages,  Z  and  Larch. 


Figure  5.1  Formalized  Object  Transformations 

In  order  to  automate  a  portion  of  the  first  transformation  process,  both  vertical  paths 
contain  a  step  for  language- specific  compilation.  Providing  an  initial  operational  capability 
^This  chapter  was  co-written  with  Captain  Kathleen  Wabiszewski.  It  also  appears  in  (Wab94). 
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toward  this  goal,  robust  language  parsers  were  designed  and  implemented.  These  parsers 
generated  similar  structural  representations  (abstract  syntax  trees)  that  established  a  basis 
for  the  preliminary  analysis  and  design  of  a  unified  target  model. 

This  chapter  focuses  on  the  evolution  of  a  Unified  Domain  Model,  whose  aim  is  the 
creation  of  a  single,  cohesive  framework  for  translating  different  source  specifications  into 
a  unifying  abstract  structure.  Four  iterations  define  this  evolution,  and  they  are  detailed 
in  Sections  5.2  through  5.5: 

1.  Evaluation  of  Abstract  Syntax  Trees  (AST) 

2.  Analysis  of  Design  Alternatives 

3.  Development  of  a  Unified  Core  Model 

4.  Development  of  Language  Specific  Extensions 

5.2  Evaluation  of  Abstract  Syntax  Trees 

As  mentioned  in  Section  5.1,  the  parser-generated  ASTs  provided  a  common  focal 
point  for  analyzing  the  structures  of  Larch  and  Z  to  establish  the  design  of  a  unified 
target  model.  This  evaluation  process  was  likened  to  an  electronic  balanced  mixer  circuit. 
Accepting  two  input  frequencies,  a  balanced  mixer  produces  four  outputs:  the  two  original 
frequencies,  the  sum,' and  the  difference.  Considering  the  two  ASTs  as  input,  the  evaluation 
produced  the  originals,  common  core  objects,  and  language  specific  objects,  as  depicted  in 
Figure  5.2. 
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Figure  5.2  AST  Evaluation  Process 


5.2.1  Common  Core  Objects.  The  evaluation  of  the  ASTs  revealed  that  both 
languages  contain  strong  similarities  in  their  conceptual  representations  of  a  specification. 
Both  languages  require  a  set  of  signatures,  axioms,  and  external  references  to  describe  a 
problem  domain.  Larch  uses  operators  with  signatures,  axiomatic  equations,  and  context 
references  in  its  specification  format.  Z  defines  a  specification  using  signatures,  predi¬ 
cates,  and  schema  referencing.  Even  though  the  syntactical  domain,  or  notations,  differ, 
the  semantic  domain,  i.e.,  the  mathematical  foundation,  remain  fundamentally  the  same. 
Consequently,  Table  5.1  identifies  a  set  of  core  objects  extracted  from  both  languages  that 
form  the  unified  domain  model. 

5.2.2  Language  Specific  Objects.  The  AST  analysis  also  revealed  differences  in 
the  way  each  language  characterized  the  common  objects.  For  example,  even  though  the 
ASTs  identify  that  both  languages  contain  a  signature,  a  Z  signature  can  use  specific 
notions  of  state  transitions,  both  the  before  state  (State)  and  the  after  state  (State’),  while 
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Table  5.1  Larch  and  Z  Commonalities 


Unifying  Object 

Larch 

Z 

Theory  Object 

Trait 

Schema  Paragraph 

Theory  Id 

Trait  Id 

Schema  Id 

Theory  Body 

Trait  Body 

Schema 

Theory  Signature 

Introduces  Clause 

Declarations 

Theory  External  Reference 

Context  References 

Schema  References 

Theory  Axioms 

Asserts  Clause 

Axiom  Part 

Larch  does  not.  Additionally,  the  Z  language  is  capable  of  explicitly  declaring  input  and 
output  variables,  while  Larch  cannot.  Therefore,  these  variances  required  an  approach 
that  captured  each  language’s  specialization,  yet  preserved  the  core  characteristics. 


5.2.S  A  Framework  for  Language  Inheritance.  One  approach  for  modeling  the 
common  core  objects  and  the  specialized  objects  is  through  language  inheritance.  Language 
inheritance  establishes  a  notion  of  a  common  base  language  that  is  inherited  by  various 
dialects  (Sys90).  These  dialects  specialize  the  common  language  in  order  to  implement 
language  specific  constructs.  This  approach  seemed  well-suited  for  modeling  the  specialized 
constructs  of  Larch  and  Z  because  each  language  can  be  represented  as  a  dialect  of  a 
common  core  language,  i.e.,  a  mathematically-based  language  composed  of  signatures, 
axioms,  and  external  references.  Establishing  this  framework  in  Refine  supports  the 
development  of  a  uiiiform  interface  for  formalized  object-oriented  models.  The  Refine 
object  base  is  capable  of  representing  inheritance  and  specialization  through  object  classes 
and  subclasses.  Figure  5.3  illustrates  an  example  of  language  inheritance  for  Larch  and 
Z  using  the  unifying  objects  defined  in  Table  5.1. 
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Figure  5.3  Language  Inheritance 


5.3  Analysis  of  Design  Alternatives 

Using  language  inheritance  as  a  framework  to  consolidate  the  similarities  and  differ¬ 
ences  between  Larch  and  Z  modified  the  initial  transformation  process  depicted  in  Figure 
5.1.  Instead  of  converging  to  a  unified  model  after  compilation,  the  new  design  focused  on 
unifying  the  two  languages  during  the  parsing  stage.  This  new  process  is  founded  on  the 
common  base  language  established  above  and  is  shown  in  Figure  5.4. 

In  order  to  implement  this  new  design,  two  possible  courses  of  action  were  developed: 

1.  Develop  transformation  programs  for  each  language  to  convert  the  grammars  into 
the  unified  model. 

2.  Refine  the  original  language  grammars  in  order  to  parse  into  the  unified  domain 
model. 
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Figure  5.4  Modified  Transformation  Process 

Since  these  paths  were  significantly  different,  an  in-depth  analysis  was  conducted  to 
select  the  best  candidate.  The  strengths  and  weaknesses  of  each  alternative  are  summarized 
in  Figure  5.5  and  discussed  in  the  two  subsequent  sections. 

5.3.1  Transformation  Approach.  Even  though  the  transformation  approach  de¬ 
creases  the  parser’s  complexity,  the  process  introduces  a  level  of  informality  into  the  uni¬ 
fied  implementation.'  This  informality  results  from  relying  on  hand-coded  algorithms  to 
construct  the  unified  model  instead  of  a  more  established  parsing  technique  that  relies 
on  machine-generated  algorithms.  Also,  since  reusable  code  is  essentially  prohibited,  the 
transformation  approach  increases  the  amount  of  transform  specializations  needed  in  the 
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SACRIFICE  WORK  ON  EXECUTION 
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Figure  5.5  Unification  Design  Alternatives 


overall  formal  process.  More  importantly,  despite  the  advantage  of  completing  more  analy¬ 


sis  of  the  execution  model,  this  model  does  not  adhere  to  the  desired  correctness  constraint. 


5.3.2  Parsing  Approach.  The  parsing  approach  complicates  the  development  of 
the  formal  language  compilers,  thereby  placing  a  time  constraint  on  performing  a  complete 
execution  model  analysis.  But,  this  approach  preserves  each  languages’  syntactical  struc¬ 
ture  in  the  unified  implementation.  By  using  Dialect  to  accept  both  the  unified  domain 
model  and  each  language’s  surface  syntax.  Dialect  generates  a  parser  for  Z  and  a  parser 
for  Larch  that  map  to  the  same  common  core  model.  Because  this  approach  preserves 
each  language’s  syntax,  thereby  fulfilling  the  correctness  requirement,  it  is  the  strongest 
candidate  for  the  unification  implementation. 
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5-4  Development  of  a  Unified  Core  Model 


After  completion  of  the  AST  evaluations  and  approach  analyses,  the  next  iteration 
in  the  evolution  of  the  unified  domain  model  focused  on  the  common  core  objects.  Based 
on  previous  experience  with  the  original  parsers  and  the  sensitivity  of  the  Dialect  tool, 
an  incremental  strategy  was  adopted  to  reduce  the  overall  complexity  of  this  development 
phase.  Using  the  three  OOA  models  as  increments,  the  following  steps  were  outlined  to 
parse  both  Larch  and  Z  into  the  unified  core; 

1.  Design  a  Unified  Core  Domain  Model 

2.  Map  Language  Commonalities  to  Unified  Core  Syntax 

3.  Implement  the  Core  Domain  Models  and  Grammars 

4.  Compile  and  Validate  Grammars 

The  following  sections  detail  these  steps  and  the  resultant  initial  capabilities  of  the 
“ULarch”  and  “U2ed”  parsers.  The  fully  operational  versions  are  described  in  Section 
5.5. 


5.4- i  Framework  for  the  Unified  Core  Domain  Model.  The  common  object  classes 
identified  during  the  AST  analysis  in  Section  5.2.1  formed  the  basis  for  the  unified  domain 
model.  In  order  to  formally  relate  these  coiiimonalities  and  their  intrinsic  properties,  an 
encapsulating  framework  was  defined.  Comparing  both  Larch  and  Z  at  a  high  level  of 
abstraction,  we  can  generally  characterize  these  languages  as  theories,  or  sets  of  statements 
used  to  describe  some  problem  domain  (Bai).  Examples  of  theory  statements  include 
domain  models,  software  systems,  and  formal  specifications.  Since  both  Larch  and  Z 
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Figure  5.6  Unified  Core  Domain  Model 


define  a  specification  as  their  top-level  object,  a  corresponding  root  object  in  the  unified 


core  was  defined  as  a  “domain  theory”.  Mapped  to  the  Rumbaugh  OOA  framework,  this 
domain  theory  was  categorized  into  three  distinct  DomainTheoryTypes:  ObjectTheory, 
DynamicTheory,  and  FunctionalTheory.  In  terms  of  multiplicity,  one  object  theory  is 
required,  while  there  may  be  zero  or  more  dynamic  and  functional  theories.  To  complete 
the  domain  theory  framework,  each  theory  type  was  defined  through  identical  aggregate 
components:  a  Theoryld  and  a  Theory  Body.  Figure  5.6  provides  a  graphical  depiction  of 
the  core  framework. 
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As  stated  above,  a  complete  cycle  of  design,  development,  and  validation  activities 
was  accomplished  for  each  of  the  domain  theory  types.  Based  on  the  fact  that  every  domain 
theory  must  have  an  object  theory,  the  first  phase  concentrated  on  the  ObjectTheory 
implementation.  The  entire  process  is  detailed  in  the  following  three  subsections.  Since 
the  other  two  phases  for  the  dynamic  and  functional  theories  mirrored  the  first  phase,  their 
development  is  summarized  in  Subsection  5.4.5. 

5.4-2  ObjectTheory  Mappings.  After  establishing  the  core  domain  framework, 
the  ObjectTheory  commonalities  of  Larch  and  Z  were  implemented.  Starting  with  the 
layer  composed  of  the  ObjectTheoryld  and  ObjectTheoryBody  classes,  additional  common 
object  classes  were  identified.  Since  the  ObjectTheoryld  is  a  leaf  node,  no  further  decompo¬ 
sition  was  possible.  The  ObjectTheoryBody,  however,  was  partitioned  into  two  additional 
layers.  The  first  tier  contained  the  ObjectTheoryDeclarations  and  ObjectTheory  Axioms. 
The  second  tier,  containing  SignatureDeclarations  and  ExternalReferences,  resulted  from 
further  decomposition  of  the  theory  declaration  component.  Figure  5.7  illustrates  all  the 
common  layers  within  the  ObjectTheory  class.  Below  these  layers,  the  composition  of  the 
two  source  languages  became  too  divergent,  thereby  requiring  language  specific  extensions. 
These  extensions  are  detailed  in  Section  5.5. 

5.4.3  Implementation  of  Domain  Models  and  Grammars.  The  establishment  of  a 
stable  domain  model  for  the  object  theory  facilitated  the  development  of  the  corresponding 
Refine  code.  The  object  classes  and  associations  in  the  domain  model  mapped  directly 
into  Refine’s  object  classes  and  map  attributes.  Analogous  to  the  development  of  the 
original  Larch  and  Z  parsers,  the  tree- attribute  structure  was  defined  by  using  object 
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Figure  5.7  Object  Theory  Body  Domain  Model 


classes  for  the  nodes  and  the  corresponding  map  attributes  for  the  links.  This  tree-attribute 
hierarchy  guided  the  modifications  for  each  language’s  grammar.  Maintaining  consistency, 
Larch  and  Z  specific  rules  were  carefully  mapped  into  a  target  unified  object  theory 
rule.  In  addition  to  re-naming  terminals  and  non-terminals  to  reflect  the  common  unified 
objects,  the  production  rules  had  to  correctly  map  to  each  formal  language’s  extensions. 


Compilation  and  Validation  of  Grammars.  As  a  direct  result  of  each 
original  grammar’s  rigorous  development,  the  compilation  of  the  unified  grammars  was 
straightforward.  The  majority  of  errors  resulted  from  ill-defined  attributes  connecting  the 
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unified  model  to  the  language  specific  models.  The  validation  process  for  the  unified  parsers 
was  accomplished  in  two  phases:  parsing  of  source  programs  and  AST  evaluations.  Since 
this  iteration  of  the  unified  parsers  was  focused  on  the  object  theory,  just  the  object  models 
of  the  counter  and  fuel  tank  domains  introduced  in  Chapter  III  were  used  as  inputs.  A 
visual  inspection  of  each  domain’s  object  theory  clearly  identified  the  boundary  between  the 
common  object  classes  and  the  specialized  ones.  Traversing  the  two  ASTs,  each  node  was 
inspected  to  verify  the  presence  of  expected  attribute  values.  As  an  additional  confirmation, 
the  ULarch  and  U.Zed  ASTs  were  compared  against  their  respective  language-specific 
ASTs.  This  process  verified  the  preservation  of  each  language’s  syntax  and  semantics, 
thus  validating  a  common  framework  for  parsing  Z  and  Larch  specifications. 

Dynamic  Theory  and  FunctionalTheory  Iterations.  As  stated  in  Subsection 
5.4.1,  the  iterations  for  both  the  dynamic  and  functional  theories  were  symmetrical  to  the 
object  theory  iteration.  The  object  classes  of  Theory  Declarations,  SignatureDeclarations, 
ExternalReferences,  and  Theory  Axioms  were  all  instantiated  with  instances  of  Dynam- 
icTheory  and  FunctionalTheory.  Complete  graphical  models  are  located  in  Appendix  E, 
and  Appendix  F  contains  the  corresponding  Refine  implementation.  For  the  validation  of 
both  theory  types,  the  counter  and  fuel  tank  domains  were  augmented  with  the  appropriate 
dynamic  and  functional  models.  The  confirmation  of  this  stage  baselined  the  Unified  Core 
Model’s  capabilities.  In  order  to  complete  the  functionality  of  these  two  unified  parsers, 
the  final  phase  required  the  addition  of  language  specific  extensions. 
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5.5  Development  of  Language  Specific  Extensions 


Since  the  top-level  hierarchy  of  both  languages  inherited  from  the  common  core 
framework,  the  required  changes  for  the  language  extensions  consisted  of  mapping  each 
specific  syntax  to  the  inherited  core.  Reusing  the  language  specific  objects  and  map  at¬ 
tributes  defined  in  the  original  parsers,  the  only  modifications  consisted  of  re-defining  the 
map  attributes  that  linked  the  core  framework  with  the  language  specific  extensions.  As 
an  example.  Figures  5.8  and  5.9  illustrate  the  ULarch  and  UZed  specific  extensions  of 
the  inherited  SignatureDeclaration  class. 

Although  the  majority  of  changes  for  both  language  extensions  was  similar,  some 
individual  syntax  alterations  were  also  necessary.  Specifically,  for  ULarch,  I^TgX  nota¬ 
tions  were  required  in  the  grammar.  Since  both  Larch  and  Z  specifications  use  lATgX 
notations,  the  production  rules  of  the  ULarch  grammar  were  changed  to  incorporate  the 
lATgX  notation  as  well.  Also,  since  there  are  significantly  more  syntactical  units  in  Z  than 
in  Larch,  the  UZed  extension  process  was  compounded.  The  following  list  details  the 
major  tasks  involved: 

1.  Distinction  Between  State  and  Event  Schemas  -  Correlated  to  the  original  parser, 
U.Zed’s  DynamicTheory  object  was  further  partitioned  into  StateTheory  and  Event- 
Theory  subtypes.  Their  internal  structures  were  identical  to  their  parent  object, 
composed  of  declarations,  external  references,  and  axioms. 

2.  Inclusion  of  Definition  Paragraphs  -  As  detailed  in  Wabiszewski’s  thesis  (Wab94),  the 
original  Z  parser  recognizes  two  major  types  of  paragraphs;  schema  and  definition. 
The  schema  paragraph  types  mapped  directly  to  the  unified  object,  dynamic,  and 
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Figure  5.8  Signature  Declaration  -  ULarch  Specific  Extension 
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functional  theories  discussed  above.  The  definition  paragraphs  were  designated  as 
another  subtype  of  DomainTheoryType,  namely  a  DefinitionTheory.  Consequently, 
all  subtypes  of  DefinitionTheory  were  successfully  appended  to  the  core  framework. 

3.  Inheritance  of  the  Mathematical  ToolKit  -  In  order  to  create  a  unified  version  of  the 
ToolKit,  the  information  pertaining  to  the  inherited  grammar  was  modified.  Since 
the  ToolKit  is  appended  to  the  core  Z  parser  at  a  low  level,  the  changes  to  the 
UToolKit  were  minimal. 

The  complete  set  of  diagrams  for  the  ULarch  extensions  are  contained  in  Appendix 
G,  while  the  Refine  code  for  the  domain  model  and  grammar  are  located  in  Appendices  H 
and  I,  respectively.  The  equivalent  UZed  appendices  can  be  found  in  Wabiszewski’s  thesis 
(Wab94). 

5.6  Summary 

Although  the  syntactic  domains  of  the  two  source  languages,  Z  and  Larch,  were 
different,  their  semantic  domains  were  conceptually  the  same.  Both  formal  specifications 
encapsulate  theories  about  a  target  problem  domain  through  sets  of  signatures  and  ax¬ 
ioms.  The  notion  of  language  inheritance  produced  a  framework  for  a  unified  core  domain 
model  and  specialized  language  dialects.  Intuitively,  the  languages’  specializations  should 
be  minimal,  since  they  are  both  founded  on  mathematical  constructs;  however,  during  this 
research  effort,  the  lack  of  a  verifiable  mechanism  for  pattern  matching  and  term  rewriting 
limited  the  depth  of  the  inherited  core  to  a  much  higher  level.  Nonetheless,  the  resultant 
unified  design  does  provide  an  initial  consolidation  of  various  formal  language  represen¬ 
tations,  which,  in  turn,  promotes  reusability  and  prevents  escalation  in  the  number  of 
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VI.  Design  of  a  Formal  Execution  Framework^ 

6. 1  Introduction 

In  Chapter  V,  Figure  5.4  depicted  a  transformation  process  that  produces  an  exe¬ 
cutable  program  from  a  unified  abstract  structure.  To  maintain  consistency,  executable 
code  generated  from  a  formal  specification  requires  a  concrete  target  model.  An  execution 
framework  is  the  initial  step  toward  building  this  target  model  because  it  identifies  the  exe¬ 
cutable  program’s  data  structures  and  functions.  The  existing  ULarch  and  VZed  parsers 
provide  the  syntactical  basis  for  this  execution  framework,  but  additional  semantic  analysis 
is  required  to  ensure  consistency.  Therefore,  this  chapter  elaborates  the  steps  necessary  to 
complete  the  compilation  analysis  phase  (refer  to  Figure  4.1)  and  then  describes  the  design 
and  development  of  an  execution  framework.  The  specific  tasks  are  outlined  below: 

1.  Semantic  Analysis 

2.  Creation  of  an  Execution  Domain  Model 

3.  Development  of  Execution  Framework  Mappings 

4.  Prototyping  an  Initial  Executable  Program 

6.2  Semantic  Analysis 

The  semantic  analysis  portion  of  the  compilation  process  consists  of  various  checks 
that  ensure  a  program  fits  together  in  a  meaningful  way  prior  to  generating  an  executable 
program  (ASU88:5).  For  this  research  effort,  two  semantic  analysis  tasks  were  identified 

'This  chapter  was  co-written  with  Captain  Kathleen  Wabiszewski.  It  also  appears  in  (Wab94). 
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to  simplify  the  translation  phase;  shorthand  expansion  and  type  checking.  In  general, 
shorthand  expansion  augments  the  AST  by  including  the  signatures  and  axioms  of  any 
referenced  components.  Type  checking  ensures  that  operators  used  in  expressions  are  not 
applied  to  incompatible  operands.  Figure  6.1  illustrates  the  sequencing  of  these  two  tasks. 


SYNTAX 

TREE 


SEMAMTIC  ANALYSIS 


. - ^ 

( - ^ 

SHORTHAND 

EXPANSION 

AUGMENTED 

TYPE¬ 

CHECKING 

s _ _ 

SYNTAX  TREE 


INTERMEDIATE 

REPRESENTATION 


Figure  6.1  Semantic  Analysis  Phases 


While  the  following  subsections  describe  the  analysis  and  design  performed  for  the 
languages’  shorthand  expansion,  it  was  decided  that  type  checking  would  not  be  addressed 
during  this  research  effort  for  two  reasons: 

1.  The  existence  and  accessibility  of  stand-alone  type-checkers,  i.e.,  MIT’s  Larch  Shared 
Language  (LSL)  Checker  (GH93)  and  DePaul  University’s  Z  Type  Checker  (ZTC) 
(Jia94),  provided  an  interim  verification  capability. 

2.  Since  type  checking  is  essentially  an  implementation  task,  it  could  be  reserved  for 
future  enhancements. 


6.2.1  Shorthand  Expansion  Analysis.  In  an  abstract  specification,  shorthand 
notations  are  used  to  promote  modularity  and  encapsulation  through  a  reduction  in  the 
amount  of  formal  text.  To  translate  a  specification  into  a  concrete  implementation  requires 
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the  expansion  of  these  notations  to  produce  a  robust  intermediate  representation.  In  a 
Larch  specification,  shorthand  expansion  consists  of  unioning  the  operators  and  axioms 
of  the  “includes”  trait  with  the  original  referencing  trait.  In  a  Z  document,  there  can  be 
many  different  types  of  shorthand  notation,  e.g.,  the  A/S  operations  and  the  numerous 
schema  calculus  expressions,  such  as  schema  inclusion. 

In  terms  of  the  unified  model,  the  schema  inclusion  notation  is  comparable  to  Larch’s 
“includes”  mechanism,  whereby  the  schemas’  signatures  are  merged  and  the  predicates  are 
conjoined  (Lig91:42).  In  contrast,  however,  the  A  and  H  notations  do  not  have  Larch 
counterparts.  Described  in  Chapter  FV  of  Wabiszewski’s  thesis  (Wab94),  these  prefixes  can 
be  attached  to  a  schema  name  in  order  to  indicate  types  of  schema  importation.  To  demon¬ 
strate  the  underlying  semantics  of  the  two  conventions,  consider  the  following  schema,  S, 
as  a  reference  point. 

5 _ 

i>  j 


Figure  6.2  Example  Schema  S 

The  succinct  notation  of  the  A  and  E  conventions  are  used  to  distinguish  updates 
from  observations.  Specifically,  Z’s  A  convention,  as  in  other  areas  of  mathematics,  is  used 
to  signify  a  change  in  state.  Recalling  that  the  tick  (’)  decoration  indicates  a  post-operation 
value,  the  implicit  definition  of  this  notation  is  given  as:  AState  =  [State]  State'].  The 
syntax  of  the  expanded  A  schema  for  schema  S  is  provided  in  Figure  6.3. 
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In  Z,  the  E!  symbol,  chosen  because  of  its  similarity  in  appearance  to  the  equivalence 
symbol  (=),  signifies  the  state  of  the  schema  before  and  after  an  operation  where  all  of 
the  schema’s  components  remain  unchanged  (Lig91:45).  The  default  definition  of  the  E 
convention  is  as  follows;  EState  =  [A5<a<e  |  vl’  =  vl  A  v2’  =  v2  A  ...  vk’  =  vk],  where 
vl.  .vk  inclusive  are  the  variables  of  State.  A  visual  representation  of  an  expanded  E  schema 
is  depicted  in  Figure  6.4. 


Figure  6.4  Expanded  Xi  Schema 

To  address  the  wide  variety  of  shorthand  notations,  two  alternative  expansion  ap¬ 
proaches  were  evaluated.  The  first  alternative  combines  the  parsing  task  with  the  short¬ 
hand  expansion,  while  the  second  alternative  maintains  a  separation  between  syntax  and 
semantics. 
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6. 2. 1.1  Addition  of  Explicit  Production  Semantics.  Although  the  compila¬ 
tion  analysis  phase  depicted  in  Figure  4.1  distinguished  between  the  parsing  and  seman¬ 
tic  analysis  phases,  some  language  compilers  do  merge  these  two  tasks.  Supporting  this 
approach,  Dialect  possesses  the  capability  to  embed  semantic  analysis  tasks  within  a 
language’s  production  rules.  The  Dialect  Users  Manual  outlines  two  situations  where 
these  explicit  production  semantics  are  effective  (Sys90:5-17): 

•  Productions  where  the  user  must  set  attributes  of  an  object  that  are  not  fully  de¬ 
scribed  by  the  syntax. 

•  Productions  that  are  used  to  augment  the  syntactic  inheritance  hierarchy. 

The  second  instance  appeared  to  be  applicable  to  this  research  effort;  however,  a 
prototyping  effort  yielded  disappointing  results.  The  production  semantics,  as  defined  in 
the  Dialect  manual,  did  not  appear  to  augment  the  ASTs,  and  it  could  not  be  discerned 
whether  the  added  production  semantics  had  any  effect  on  the  languages’  rules.  Further¬ 
more,  it  seemed  that  the  production  semantics  required  terminal  objects  (i.e.,  the  lowest 
level  objects  in  the  domain  models)  in  its  definition,  which  constrained  the  effective  range 
of  this  approach.  Therefore,  this  alternative  was  deemed  inappropriate. 

6. 2. 1.2  Development  of  Traversal  Algorithms.  The  second  alternative  for 
augmenting  the  ASTs  required  the  creation  of  tree  traversal  algorithms.  Essentially,  this 
methodology  uses  Refine  programs  to  manipulate  the  object  base  created  during  parsing, 
thereby  expanding  the  shorthand  notations.  As  a  prototype,  the  following  generic  traversal 
steps  were  developed: 
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1.  Locate  the  shorthand  notation  objects. 


2.  For  each  included  object,  collect  its  signatures  and  axioms. 

3.  Augment  the  object  base  with  the  collected  signatures  and  axioms. 

After  prototyping  the  predefined  algorithm,  the  resultant  ASTs  were  viewed  for  ac¬ 
curacy  and  completeness.  The  test  specification  had  been  augmented  with  the  collected 
signatures  and  invariants.  Also,  because  this  approach  maintained  disjoint  syntactical  and 
semantic  phases,  the  grammars’  production  rules  were  not  corrupted.  Supported  by  this 
evidence,  this  alternative  was  selected  for  implementing  shorthand  expansions. 

6.2.2  Implementation  of  Traversal  Algorithms.  For  manageability,  the  imple¬ 
mentation  of  the  traversal  algorithms  was  divided  into  two  separate  phases.  Contained  in 
Appendix  J,  the  completed  routines  are  depicted  in  the  structure  chart  in  Figure  6.5. 


Figure  6.5  Traversal  Routines 
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In  the  first  implementation  phase,  the  successful  test  algorithm  was  directly  trans¬ 
lated  into  routines  for  the  ULarch  “includes”  notation  and  UZed’s  schema  inheritance. 
A  summary  of  the  respective  routines  is  provided; 

1.  Make-Includes-Link:  An  “Including”  trait’s  theory  is  expanded  by  unioning  the 
Included  trait’s  operators  and  axioms. 

2.  Make-Schema-Inclusion:  A  state  schema’s  signature  is  unioned  with  the  refer¬ 
enced  object  schema’s  signature.  Additionally,  the  predicates  of  both  schemas  are 
conjuncted  together  within  the  state  schema’s  predicate. 

For  the  second  phase  of  the  iteration,  based  on  frequency  of  use  and  correlation 
to  the  Rumbaugh  model,  the  more  complicated  A  and  Z  notations  were  implemented. 
Due  to  time  constraints,  the  algorithms  for  the  less  frequently  used  Z  schema  calculus 
expressions  were  reserved  for  future  enhancements.  The  specific  routines  developed  for  the 
two  conventions  are  listed  below: 

1.  Make-Delta-SchemaS:  A  A  reference  is  expanded  by  unioning  the  signature  of 
the  A  schema  with  the  signature  of  the  referenced  schema.  Likewise,  the  predicates 
of  both  schemas  are  conjuncted  together.  A  boolean  annotation  attribute,  delta-link, 
is  set  to  true. 

•  Make-Delta- Vars:  If  its  delta-link  attribute  is  true,  the  A  signature  is  ex¬ 
panded  a  second  time  to  include  the  ticked  counterparts  of  the  referenced  ob¬ 
ject’s  variables.  Also,  the  predicate  is  expanded  to  include  the  corresponding 
constraints  placed  on  those  ticked  variables  (See  Figure  6.3). 
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2.  Make-Xi-Schemas:  A  E  reference  is  expanded  by  unioning  the  signature  of  the  E 
schema  with  the  signature  of  the  referenced  schema.  Likewise,  the  predicates  of  both 
schemas  are  conjuncted  together.  A  boolean  annotation  attribute,  xi-link,  is  set  to 
true. 

•  Make-Xi-Vars:  If  its  xi-link  attribute  is  true,  the  E  signature  is  expanded  a 
second  time  to  include  the  ticked  counterparts  of  the  referenced  object’s  vari¬ 
ables.  Also,  the  predicate  is  expanded  to  include  the  corresponding  constraints 
placed  on  both  the  ticked  and  unticked  variables  (See  Figure  6.4). 

6.2.3  Validation  of  Algorithms.  The  testing  and  validation  of  the  traversal  al¬ 
gorithms  consisted  of  visually  inspecting  the  augmented  ASTs  with  Object  Inspector. 
During  this  process,  two  types  of  errors  were  detected:  misplacement  within  the  hierarchy 
and  replication  of  variables.  In  the  first  case,  incorrect  attribute  references  caused  the 
“included”  signatures  and  axioms  to  be  appended  to  the  wrong  parent  class.  In  the  second 
case,  the  temporary  set  used  to  collect  the  referenced  signatures  and  axioms  was  not  being 
emptied  between  enumerations.  Upon  correction  of  these  errors,  the  traversal  algorithms 
generated  the  correct  results,  thereby  producing  robust  intermediate  representations  of 
the  source  languages.  The  next  phase  of  development  focused  on  the  target  execution 
framework. 

6.3  Creation  of  an  Execution  Domain  Model 

After  completing  the  compilation  analysis  phase,  the  first  step  in  designing  an  execu¬ 
tion  framework  required  the  creation  of  a  domain  model  for  the  target  execution  language. 
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Refine.  Analyzing  the  syntax  of  the  language  produced  four  major  object  classes  as  the 
target  data  structures:  object  classes,  map  attributes,  functions,  and  rules.  The  object 
classes  and  map  attributes  were  identified  as  terminal  objects,  while  the  function  and  rule 
classes  each  decomposed  into  local  parameters  and  a  set  of  preconditions  and  postcon¬ 
ditions.  Figure  6.6  illustrates  the  major  object  classes  of  the  execution  domain  model. 
Once  defined,  the  objects  and  associations  in  the  domain  model  mapped  directly  into  the 
object  classes  and  map  attributes  of  a  Refine  description.  This  description  reflected  the 
execution  domain  model,  thus  establishing  a  concrete  target  for  the  execution  framework 
mappings.  (See  Appendix  K  for  the  complete  graphical  model  and  Appendix  L  for  the 
corresponding  Refine  implementation.) 


Figure  6.6  Execution  Target  Domain  Model 
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6-4  Development  of  Execution  Framework  Mappings 


Developing  a  translation  process  between  the  source  and  target  domain  models  re¬ 
quired  mapping  the  ULarch  and  U^d  objects  to  the  corresponding  Refine  objects. 
Three  execution  maps  were  developed  to  correlate  with  the  unified  framework:  an  object 
theory,  a  dynamic  theory,  and  a  functional  theory  map.  A  two  phase  process  was  used  for 
each  mapping.  First,  an  initial  translation  model  defined  the  appropriate  Refine  object 
classes.  Since  an  object  theory  models  the  structure  of  a  system  and  may  identify  some 
initialization  routines,  the  target  objects  for  this  mapping  were  defined  as  Refine  object 
classes,  map  attributes,  and  functions.  Refine  functions  were  also  defined  for  both  the 
dynamic  and  functional  theories,  since  the  former  captures  a  system’s  static  states  and 
events,  while  the  latter  models  data  transformations. 

The  second  phase  of  each  mapping  process  required  an  analysis  of  both  the  ULarch 
and  UZed  models  in  order  to  match  their  individual  structures  to  the  corresponding  RE¬ 
FINE  target  components.  While  similar  dynamic  and  functional  theory  mappings  were 
produced,  the  object  theory  mappings  were  significantly  different  because  UZed’s  object 
theory  predicates  are  realized  after  state  initialization,  i.e.,  within  the  subsequent  dynamic 
and  functional  theories.  As  a  result  of  this  difference,  the  lower  right  portion  of  Table  6.1 
remains  empty,  while  Table  6.2  is  complete. 

6.5  Prototyping  an  Initial  Executable  Program 

The  feasibility  of  generating  code  from  the  execution  maps  was  demonstrated  by 
prototyping  an  executable  shell  for  the  counter  and  fuel  tank  specifications.  The  execu¬ 
tion  shells  contained  the  required  object  classes,  map  attributes,  and  function  names  for 


6-10 


Table  6.1  ULarch  and  UZed  Object  Theory  Maps 


Execution  Target  Object 

ULarch  Source  Object 

VZed  Source  Object 

Object  Class  Name 

Theory  Id 

Object  Theory  Id 

Map  Attributes 

Attribute  Name 

Attribute  Domain 
Attribute  Range 

Tuple  Object 

Tuple  Field  Ids 

Theory  Id 

Tuple  Field  Sort  Id 

Object  Theory  Declarations 
Basic  Identifiers 

Object  Theory  Id 

Any  Expressions 

Functions 

Function  Name 

Function  Parameters 
Function  Parameter  Type 
Function  Return  Type 
Function  Let  Statements 
Function  Preconditions 
Function  Postconditions 

Operators 

Operator  Name 
Quantifier  Variable  Ids 
Quantifier  Sort  Id 
Operator  Range  Id 
Theory  Axioms 

Theory  Axioms 

Theory  Axioms 

creating  an  executable  program.  The  shells  were  created  by  a  sequence  of  four  translation 
algorithms,  illustrated  in  Figure  6.7  and  described  below: 


1.  Make  Object  Class:  Translates  application  objects  in  a  formal  specification  into  Re¬ 
fine  object  classes. 


Table  6.2  ULarch  and  VZed  Dynamic  and  Functional  Theory  Maps 


Execution  Target  Object 

ULarch  Source  Object 

VZed  Source  Object 

Functions 

Function  Name 

Function  Parameters 
Function  Parameter  Type 
Function  Return  Type 
Function  Let  Statements 
Function  Preconditions 
Function  Postconditions 

Operators 

Operator  Name 
Quantifier  Variable  Ids 
Quantifier  Sort  Id 
Operator  Range  Id 
Theory  Axioms 

Theory  Axioms 

Theory  Axioms 

St  ate/ Event /Fun  Theory  Body 

St  ate/ Event /Fun  Id 

State/Event /Fun  Declarations 

Any  Expressions 

Identifiers 

Any  State/Event/Fun  Predicates 
State/Fun  Post  Predicates 
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2.  Make  Attributes:  Finds  the  formal  representation  of  an  object’s  attributes  and  trans¬ 
lates  them  into  map  attributes  with  the  appropriate  domain  and  range  values. 

3.  Make  Functions:  Translates  the  formal  operations  defined  in  ULarch  and  UZed  and 
creates  a  corresponding  function  name. 

4.  Print  Program:  Outputs  the  executable  shell.  The  appropriate  object  classes,  map 
attributes,  and  function  names  are  listed  in  the  correct  REFINE  format. 

Appendix  M  contains  the  initial  translation  algorithms. 


Figure  6.7  Translation  Algorithms 


6.5.1  Deficiencies  in  the  Execution  Maps.  Constrained  by  time,  the  execution 
mappings  were  limited  to  a  subset  of  the  major  object  classes  within  the  Refine  target 
domain  model  (refer  to  Figure  6.6).  As  a  result,  the  initial  prototyping  effort  did  not 
complete  the  translation  mechanism  for  the  target  model’s  function  and  rule  object  classes. 
These  uncorrected  deficiencies  are  detailed  below. 
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1.  Make-Functions:  This  mapping  does  not  currently  translate  formal  parameters  and 
theory  axioms  into  appropriate  function  parameters,  preconditions,  and  postcondi¬ 
tions.  The  translation  must  differentiate  between  theory  axioms  used  as  precondi¬ 
tions  and  those  used  as  postconditions. 

2.  Make-Rules:  The  algorithm  and  mapping  for  this  Refine  object  class  does  not  exist. 
This  translation  determines  the  sequences  of  events  based  on  the  state  transition 
tables. 

6.6  Summary 

Developing  an  execution  framework  proved  extremely  useful  for  demonstrating  the 
feasibility  of  generating  code  from  a  formal  specification.  The  framework  established  the 
target  data  structures  and  functions  for  a  consistent  and  correct  translation  process.  It  also 
became  the  foundation  for  developing  the  execution  maps  from  the  unified  source  models 
into  the  Refine  target  model.  From  the  execution  maps,  specific  translation  algorithms 
were  created  to  generate  executable  Refine  code  for  the  ULarch  and  XJZed  counter  and 
fuel  tank  specifications. 
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VII.  Conclusions  and  Recommendations 


This  chapter  summarizes  the  accomplishments  achieved  in  this  research  and  describes 
the  general  and  specific  conclusions  concerning  the  development  of  a  formal  object  trans¬ 
formation  process.  Additionally,  this  chapter  presents  some  recommendations  for  future 
research. 

7.1  Summary  of  Accomplishments 

The  objective  of  this  study  was  to  formalize  the  object-based  composition  approach 
using  Larch.  Three  steps  were  defined  to  accomplish  this  objective: 

1.  Design  and  develop  an  algebraic  transformation  process  using  OMT  models  as  the 
source  representation  and  Larch  as  the  target  representation 

2.  Develop  a  unified  abstract  framework  by  comparing  the  similarities  and  differences 
between  Larch  and  Z. 

3.  Based  on  the  unified  abstract  structure,  design  an  initial  execution  framework 

These  steps  were  accomplished  using  an  evolutionary  development  approach.  The 
first  evolution  produced  an  algebraic  transformation  process  that  formalizes  the  OMT 
object,  dynamic,  and  functional  models.  This  evolution  demonstrated  that  Larch  con¬ 
tains  suitable  notations  for  expressing  object-oriented  concepts.  The  second  and  third 
evolutions  produced  a  robust,  unified  Larch  parser  demonstrating  the  notion  of  language 
inheritance.  Additionally,  the  unified  Larch  parser  established  a  stable  foundation  for 
developing  an  execution  framework,  the  objective  of  the  last  evolution.  Together,  these 
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evolutions  demonstrate  the  feasibility  of  formally  extending  object-oriented  domain  models 
using  algebras  and  translating  the  formal  models  into  an  execution  framework. 

7.2  General  Conclusions^ 

Listed  below  are  general  conclusions  drawn  from  this  research: 

1.  Analyzing  the  abstract  syntax  trees  of  Larch  and  Z  specifications  demonstrated  that 
these  formal  languages  contain  a  common  set  of  core  constructs  suitable  for  creating 
a  canonical  framework  for  formalized  object  models.  This  unified  framework  fulfills 
the  notion  of  language  inheritance  whereby  a  a  general  model  for  formal  languages 
exist  with  small  variants  known  as  “dialects”.  Additionally,  the  development  of  a 
unified  model  establishes  a  front-end  for  formal  system  composition.  This  front- 
end  can  support  three  principal  processes:  code  generation,  theorem  proving,  and 
design  refinement,  as  depicted  in  Figure  7.1.  The  unified  model  forms  the  basis 
for  creating  interface  languages  for  the  purpose  of  specification  execution.  Theorem 
proving  sentences  can  also  be  generated  from  the  unified  model  for  input  into  a 
theorem  prover  to  verify  a  specification.  Finally,  the  unified  framework  can  produce 
synthesis  diagrams  to  support  the  notion  of  theory-based  design  refinement  (Smi90) 
(BFG+94). 

2.  The  evolutionary  development  strategy  is  well-suited  for  developing  a  formal  language 
compiler  because  the  compilation  phase  can  be  decomposed  into  several  stages.  Each 

^This  section  was  co-written  with  Captain  Kathleen  Wabiszewski.  It  also  appears  in  (Wab94). 
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UNIFIED  AST 


Figure  7.1  Transformation  Process 


stage  produces  an  operational  product  demonstrating  a  minimum  set  of  capabilities, 
and  each  incremental  product  is  easily  extensible. 

3.  Developing  object-oriented  domain  models  for  Larch  and  Z  clarified  the  languages’ 
structure  by  identifying  the  important  objects  and  associations.  The  established 
domain  models  provided  a  well-defined  blueprint  guiding  the  implementation  of  the 
Larch  and  Z  grammars  in  Refine. 

4.  The  Refine  environment  simplifies  the  development  of  a  formal  language  parser  and 
an  initial  execution  framework  by  providing  compilation  tools,  i.e.,  Dialect  and 
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Object  Inspector.  Dialect  handles  token  formation  and  creates  an  explicit  hi¬ 


erarchy  for  Larch  using  a  BNF  notation.  These  hierarchies,  in  the  form  of  abstract 
syntax  trees  (ASTs),  are  stored  in  the  object  base  and  viewed  using  OBJECT  Inspec¬ 
tor.  A  visual  representation  is  extremely  beneficial  because  it  allows  one  to  inspect 
the  parse  tree  and  understand  the  underlying  structure  of  the  formal  language.  ASTs 
also  provide  a  strong  foundation  to  perform  semantic  analysis  and  to  begin  building 
an  execution  framework. 

7.5  Specific  Conclusions 

Specific  conclusions  that  can  be  drawn  from  developing  an  algebraic  transformation 
process  and  a  unified  Larch  parser  are  presented  below: 

1.  Algebraic  specifications,  specifically  Larch,  can  formally  represent  object-oriented 
constructs.  Chapter  III  showed  how  Larch  contained  suitable  notations  to  represent 
object  attributes,  inheritance,  aggregation,  and  operator  behavior. 

2.  The  Unified  Larch  Parser  successfully  parses  a  wide  range  of  Larch  traits.  Ap¬ 
pendix  N  contains  a  user’s  manual  for  running  the  parser  and  Appendix  O  contains 
a  list  of  successfully  parsed  traits. 

3.  The  Unified  Larch  Parser  generates  well-defined  abstract  syntax  trees  simplifying 
the  following  compilation  phases: 

•  Semantic  Analysis 

•  Code  Generation 
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As  shown  in  Chapter  IV,  the  ambiguity  encountered  in  the  original  grammar  pro¬ 
duced  a  parser  that  generated  incredibly  deep  and  unintelligible  ASTs.  Any  attempt 
to  perform  semantic  analysis  or  code  generation  on  this  structure  would  have  caused 
numerous  work-arounds  to  properly  augment  the  tree  and  translate  it  into  an  exe¬ 
cutable  program.  On  the  other  hand,  the  revised  parser,  based  on  a  stable  domain 
model,  generated  succinct  AST  representations.  These  ASTs  simplified  the  semantic 
analysis  tasks  of  shorthand  expansion  and  the  initial  execution  translation  described 
in  Chapter  VI. 

4.  The  Unified  Larch  Parser  is  extensible.  Larch’s  domain  model  and  syntax  allow 
developers  to  extend  the  current  language  model  in  a  straightforward  fashion  by 
defining  new  subclasses.  This  flexibility  was  demonstrated  in  Chapter  IV  when  new 
axiomatic  terms  were  added  to  the  existing  domain  model  and  grammar. 

T.4  Recommendations  for  Future  Research 

Listed  below  are  areas  that  require  further  research: 

1.  Extend  the  Unified  Abstract  Framework  -  The  goal  for  establishing  a  unified  abstract 
framework  is  to  provide  a  common  base  language  with  small  variant  specializations 
or  dialects.  However,  the  current  framework  does  not  reflect  a  true  common  core  be¬ 
cause  each  language  has  not  been  reduced  into  its  most  significant  form.  Decreasing 
the  language  specific  dependencies  requires  pushing  the  specializations  down  to  the 
lowest  level  in  the  unified  model.  Pushing  is  defined  as  the  consolidation  and  resolu¬ 
tion  of  similar  constructs  via  pattern  matching  and  term  rewriting.  Pattern  matching 
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is  applied  to  the  syntactic  components  of  the  ASTs  to  identify  language  commonal¬ 
ities.  Mathematically  verifiable  procedures  known  as  term  rewriting  are  then  used 
to  translate  the  commonalities  into  a  target  canonical  form.  When  the  terms  can  no 
longer  be  rewritten,  they  are  considered  to  be  in  a  normal  form.  This  form  represents 
the  complete  common  base  language  expressing  the  language’s  meaning  without  any 
loss  of  generality. 

2.  Identify  Theorem  Proving  Tasks  -  The  refinement  process  from  a  formal  specification 
into  an  executable  implementation  should  demonstrate  that  the  specification  remains 
consistent  and  complete  (NS91).  Proving  consistency  and  completeness  requires  iden¬ 
tifying  theorem  proving  tasks.  These  tasks  ensure  that  the  implementation  possesses 
the  right  properties,  for  example: 

•  Does  the  specified  operation  function  correctly? 

•  Are  the  proper  constraints  on  operations  implemented? 

•  Do  the  specified  invariants  hold  over  time? 

•  Does  the  operation  guarantee  the  correct  final  state  based  on  the  initial  state 
and  event? 

•  Is  an  object  prevented  from  being  in  two  different  states  at  one  time? 

•  Is  an  operation  guarded  by  the  proper  pre-conditions? 

3.  Complete  the  Execution  Framework  -  To  complete  the  execution  framework  the  fol¬ 
lowing  tasks  are  required: 
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•  Type  Checking  -  Key  component  during  semantic  analysis  ensuring  that  opera¬ 
tors  have  compatible  operands  (ASU88).  Although  a  stand-alone  LSL  checker 
exists,  incorporating  a  type  checker  in  the  Refine  environment  provides  a  seam¬ 
less  compilation  path  for  the  formal  object  transformation  process. 

•  Additional  Semantic  Checks  -  Required  to  complete  the  translation  of  axiomatic 
equations  in  Larch  and  schema  predicates  in  Z  into  Refine  functions.  The 
main  emphasis  for  this  task  centers  around  identifying  the  appropriate  pre-  and 
postconditions  to  establish  the  corresponding  Refine  transform  operations. 

•  Execution  Translation  -  Final  task  in  completing  the  execution  framework.  This 
task  produces  an  executable  program  of  a  formally  specified  problem. 

•  System  Test  -  Performed  to  validate  the  formal  execution  phase.  The  established 
validation  domains,  counter  and  fuel  tank  should  be  used  to  demonstrate  and 
validate  the  specification’s  behavior.  Additionally,  larger  domains  should  be 
evaluated  to  validate  the  properties  of  scalability  and  completeness. 

•  System  Verification  -  Required  to  verify  the  consistency  of  the  execution  transla¬ 
tion  (i.e..  Larch  Behavior  =>  Refine  Behavior).  For  example,  theorem  prov¬ 
ing  tasks  need  to  be  identified  to  check  that  quantified  expressions  in  Larch 
are  consistent  with  the  quantified  expressions  in  the  Refine  program. 

The  recommendations  described  above  are  depicted  in  Figure  7.2  showing  the  in¬ 
tegration  of  additional  semantic  analysis,  theorem  proving,  and  execution  tasks  to 
augment  the  current  transformation  process. 
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Figure  7.2  Modified  Transformation  Process 


4.  Expand  the  Validation  Domains  -  A  simplistic  validation  was  conducted  on  the  al¬ 
gebraic  transformation  process  using  the  counter  and  fuel  tank  domains.  To  provide 
a  robust  validation  of  the  completeness  and  consistency  claims,  additional  domains 
need  to  be  evaluated.  One  domain  to  consider  is  an  Air  Force  Wing  command  and 
control  domaiiv  designed  by  Hunt  and  Sarchet  (Hun94)  (Sar94). 

5.  Model  State  Transition  Tables  Algebraically  -  To  complete  the  algebraic  transforma¬ 
tion  process,  the  state  transition  tables  should  be  formally  represented  in  a  Larch 
specification.  A  formal  description  of  a  state  transition  table  should  include  an  ob- 
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ject’s  current  state,  event,  and  next  state.  In  addition,  the  state  transition  description 
should  remain  consistent  with  the  overall  system  description. 

6.  Include  Multiple  Inheritance  in  the  Algebraic  Framework  -  Multiple  inheritance  is 
an  important  object-oriented  construct,  but  it  complicates  a  formal  specification 
by  introducing  additional  operators  and  invariants  from  varions  “parent”  traits.  If 
a  child  trait  contains  multiple  inheritance,  its  formal  representation  must  use  and 
correctly  combine  its  parent’s  operators  and  axioms.  Future  enhancements  to  the 
algebraic  transformation  phase  should  consider  incorporating  multiple  inheritance. 

7.  Enhance  the  Unified  Larch  Parser  -  The  current  implementation  of  the  Larch 
parser  uses  parentheses  to  disambiguate  between  certain  algebraic  terms.  These 
parentheses  are  required  to  provide  a  more  concrete  description  of  the  grammar  (i.e., 
reduce  the  level  of  abstraction),  but  they  also  force  a  user  to  a  specific  format  for 
representing  their  traits.  Therefore,  future  research  should  investigate  reducing  the 
parenthesis  dependency  while  keeping  the  grammar  intact. 

7.5  Final  Comments 

Formal  methods,  specifically  algebraic  languages,  play  an  important  role  in  improv¬ 
ing  the  specification  and  composition  of  software  systems.  These  methods  are  precise  and 
unambiguous  and  can  complement  the  current  object-oriented  perspective  by  providing 
a  seamless  transition  from  a  visual  system  description  into  a  concise  system  specifica¬ 
tion.  The  algebraic-based  execution  framework  developed  during  this  study  demonstrates 
the  feasibility  of  integrating  the  practical  object-oriented  approach  with  the  more  precise 
algebraic-based  method.  In  addition,  this  research  provides  an  initial  capability  for  ex- 
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ecuting  Larch  specifications  establishing  a  foundation  for  verifying  the  correctness  of  a 
specification  prior  to  design  and  implementation.  This  capability  improves  the  reliability 
and  outcome  of  a  software  system  ensuring  that  the  simulated  behavior  mirrors  the  original 
specification. 
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Appendix  A.  Counter  Domain  Traits 


This  appendix  contains  the  Counter  domain’s  formal  specifications.  Developed  by 
following  the  Larch  transformation  heuristics  described  in  Chapter  III,  these  traits  sup¬ 
port  the  notion  of  producing  algebraically-based  system  specifications.  Additionally,  these 
traits  supported  the  validation  of  the  unification  and  execution  phases  acting  as  the  source 
(i.e.,  the  input)  to  generate  an  executable  shell.  These  traits  have  been  typed-checked 
using  the  LSL  checker  obtained  from  MIT. 


y.Obj  ectTheory 
Counter:  trait 
includes  Integer 

C  tuple  of  value,  limit:  Integer 
introduces 
new:  —*  C 
asserts  V  c:  C 
new. value  ==  0; 
new. limit  ==  100; 
c . value  >  0 ; 
c. limit  >  c. value 


‘/.Funct  ionalTheory 
Increment :  trait 
includes  Counter 
introduces 
addl:  C  — >  C 
asserts  V  c:  C 

addl (new)  ==  [(c. value  +  1),  c. limit]; 

addl(c)  ==  if  c. value  <  c. limit  then  [(c. value  +  1),  c. limit]  else 

[c. value,  c. limit] 


y.Funct ionalTheory  ' 

Add :  trait 

includes  Counter 
introduces 

addvalue:  C,  Integer  —*  C 
asserts  V  c:  C,  v:  Int 

addvalue(new,  v)  ==  if  new. limit  >  v  then  [(c. value  +  v) ,  c. limit]  else 

[c . value ,  c . 1 imit] ; 

addvalue(c,  v)  ==  if  (c. value  +  v)  <  c. limit  then  C(c. value  +  v) ,  c. limit]  else 

[c. value,  c. limit] 
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'/.FunctionalTheory 
Subtract:  trait 
includes  Counter 
introduces 

subvalue:  C,  Integer  — >•  C 
asserts  V  c:  C,  v:  Int 

subvalue(c,  v)  ==  if  (c. value  -  v)  >  0  then 

[(c. value  -  v) ,  c. limit]  else  [c. value,  c. limit] 
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Appendix  B.  Fuel  Tank  OMT  Analysis  Models  and  State  Transition  Table 

The  Fuel  Tank  Analysis  Models  were  selected  as  a  validation  domain  for  the  formal 
object  transformation  process.  This  appendix  contains  the  OMT  analysis  models  and 
state  transition  table  used  to  support  the  algebraic  transformation  process,  the  unification 
process,  and  the  final  execution  process.  These  models  were  developed  by  Hartrum  (HB94). 


Fuel  Tank 


tat^SimTime:  Time 
inpulFlowRate:  FlowRate 
outpulFlowRate:  FtowRate 

fuelLevel:  Real 
capacity:  Real 

tankWeight:  Real 
fuelDensity;  Real 


Figure  B.l  Fuel  Tank  Object  Model 


Table  B.l  Fuel  Tank  State  Transition  Table. 


Current 

Event 

Guard 

Next 

Action 

Empty 

St  art  Fill 

Filling 

Schedule(TankFull) 

Filling 

StopFill 

fueljtevel  =  capacity 

Full 

Cancel(TankFull);  update_level 

Filling 

StopFill 

fuelJtevel  <  capacity 

PartiallyFilled 

Cancel(TankFull);  update_level 

Filling 

TankFull 

Full 

Overflow;  updateJevel 

Filling 

StartUse 

FillAndUse 

Cancel(TankFull);  update_level 

Full 

St  art  Fill 

Full 

Overflow 

Full 

StartUse 

Using 

Schedule(TankEmpty) 

Using 

TankEmpty 

Empty 

ChangeFuelFlow(  0 ) ; 
update-level 

Using 

StopUse 

PartiallyFilled 

Gancel(TankEmpty); 

updateJevel 

Using 

StartFill 

FillAndUse 

C  ancel  ( TankEmpty ) ; 
update-level 

PartiallyFilled 

St  art  Fill 

Filling 

Schedule(TankFull) 

PartiallyFilled 

StartUse 

Using 

Schedule(TankEmpty) 

FillAndUse 

StopUse 

Filling 

Schedule(TankFull); 

update-level 

FillAndUse 

StopFill 

Using 

Schedule(TankEmpty ) ; 
update-level 
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StartFill(flow_rate)/Schedule(TankFull) 


StopFill[fuel_level=capacity]/Cancel(TaiikFull);  updatejevel 


Figure  B.2  Fuel  Tank  Dynamic  Model 
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Figure  B.3  Fuel  Tank  Functional  Model  -  1 


B-4 


Sim  Qock 


Figure  B.4  Fuel  Tank  Functional  Model  -  2 
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Appendix  C.  Fuel  Tank  Domain  Traits 


This  appendix  contains  the  Fuel  Tank  domain’s  formal  specifications.  Developed 
by  following  the  algebraic  transformation  heuristics  outlined  in  Chapter  III,  these  traits 
establish  the  feasibility  of  formally  extending  the  OMT  analysis  models  using  Larch. 
These  traits  were  used  as  input  into  the  unification  and  execution  phases  to  produce  an 
initial  executable  Fuel  Tank  program.  All  of  the  traits  have  been  typed-checked  using  the 
LSL  checker  obtained  from  MIT. 


'/.ObjectTheory 
FuelTank:  trait 
includes  Integer 

FT  tuple  of  tankSimTime :  T,  inputFlowRate,  outputFlowRate:  FR, 
fuelLevel,  capacity,  tankWeight,  fuelDensity:  Int 

introduces 

fuelTankWeight :  FT  — »•  Int 
asserts  V  ft;  FT 

ft. fuelLevel  <  ft. capacity; 

fuelTankWeight (ft)  ==  ft .tankWeight  +  (ft .fuelDensity  *  ft .fuelLevel) 

‘/.DynamicTheory 
EmptyState:  trait 

includes  FuelTank(Int  for  FR) 
introduces 

empty:  FT  — >  Bool 
asserts  V  ft:  FT 

empty(ft)  ==  (ft . fuelLevel  =  0)  A  ((ft . inputFlowRate  =  0)  A  (ft . outputFlowRate  =  0)) 

'/.DynamicTheory 
FullState:  trait 

includes  FuelTank(Int  for  FR) 
introduces 

full;  FT  — *■  Bool 
asserts  V  ft:  FT 

full(ft)  ==  (ft .fuelLevel  =  ft. capacity)  A  ( (ft . inputFlowRate  =  0) 

A  '(ft • outputFlowRate  =0)) 

'/.DynamicTheory 
FillingState:  trait 

includes  FuelTank (Int  for  FR) 
introduces 

filling;  FT  —+  Bool 
asserts  V  ft:  FT 

filling(ft)  ==  ((ft.fuelLevel  >  0)  A  (ft.fuelLevel  <  ft. capacity)) 

A  ( (ft. inputFlowRate  >  0)  A  (f t. outputFlowRate  =  0)) 


C-1 


y.DynamicTheory 
UsingState:  trait 

includes  FuelTank(Int  for  FR) 
introduces 

using:  FT  — Bool 
asserts  V  ft;  FT 

using(ft)  ==  ((ft.fuelLevel  >  0)  A  (ft.fuelLevel  <  ft. capacity)) 

A  ((ft . inputFlowRate  =  0)  A  (ft . outputFlowRate  >  0) ) 


y.DynamicTheory 
StartFill:  trait 

includes  FuelTankdnt  for  FR) 
introduces 

signalStartFill:  — *•  Bool 
asserts  V  ft:  FT 

signalStartFill  ==  ft . inputFlowRate  >  0 


'/.DynamicTheory 
StopFill:  trait 

includes  FuelTankdnt  for  FR) 
introduces 

signalStopFill:  — +  Bool 
asserts  V  ft;  FT 

signalStopFill  ==  ft . inputFlowRate  =  0 

■/.DynamicTheory 
StartUse:  trait 

includes  FuelTank(Int  for  FR) 
introduces 

signalStartUse:  —>■  Bool 
asserts  V  ft:  FT 

signalStartUse  ==  f t . outputFlowRate  >  0 

'/.DynamicTheory 
StopUse:  trait 

includes  FuelTankdnt  for  FR) 
introduces 

signalStopUse;  — »•  Bool 
asserts  V  ft:  FT 

signalStopUse  ==  ft . outputFlowRate  =  0 


■/.FunctionalTheory 
Determineinterval:  trait 

includes  FuelTankdnt  for  T) ,  SimClock(Int  for  T) 
introduces 

interval:  FT,  C  — ►  Int 
asserts  V  ft;  FT,  c:  C 
interval (ft,  c)  >  0; 

intervaKft,  c)  ==  if  (c . simTime  >  ft .tankSimTime)  then  (c.simTime  -  ft .tankSimTime) 
else  0 
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'/.FiinctionalTheory 
CalculateFilledLevel:  trait 

includes  FuelTank(Int  lor  FR) ,  SimClock(Int  lor  T) ,  Determineinterval 
introduces 

lilledLevel:  FT,  Int  — >  Int 
asserts  V  It:  FT,  c:  C,  t;  Int 

lilledLevel  (It,  t)  ==  il  (t  =  0)  then  It 

else  [c.simTime,  It . inputFlowRate,  It . outputFlowRate , 
(It .luelLevel  +  ( interval (It ,  c)  * 
It.inputFlowRate)) ,  It. capacity.  It . tankWeight , 
It.luelDensity] 


y.Funct  ionalTheory 
PredictTankFullTime :  trait 
includes  FuelTank 
introduces 

overllowEventTime :  FT  — *•  T 
asserts  V  It:  FT,  c:  C,  t:  T 

overllowEventTime(lt)  ==  il  (It . inputFlowRate  ^  0) 

then  (It.tankSimTime  +  ( (It . capacity  -  It .luelLevel)/ 

It . inputFlowRate) ) 


else  0 


Appendix  D.  REFINE  Code  for  the  State  Transition  Table 


This  appendix  contains  the  Refine  code  for  the  State  Transition  Table  (STT),  il¬ 
lustrated  in  Figure  E.5,  Appendix  E.  A  formal  domain  model  and  grammar  does  not 
exist  for  the  STT  because  of  the  limitations  in  both  Z  and  Larch  to  formally  specify  the 
entries  in  the  state  transition  tables.  Thus,  to  complete  a  formal  implementation  of  the 
transformation  process,  a  grammar  and  domain  model  were  developed  to  parse  the  STT 
generating  initial  objects  to  be  used  in  the  execution  framework. 


! !  in-package ("RU") 

!!  in-grciinmar( 'user) 

#1  I 

File  name:  stt.re 

Description:  The  following  program  defines  the  State  Transition  Table 
(STT)  Domain  Model  and  the  Grammar.  The  STT  is  part  of  the  DMT 
analysis  models  and  is  required  to  create  a  complete  and  accurate 
execution  model  for  the  formal  transformation  process.  Compilation  of 
the  domain  model  and  grammar  generates  an  STT  parser  for  state 
transition  tables  created  using  the  Rumbaugh  method.  Latex  specific 
notations  are  used. 

I  I# 


•/, - 

'/.  STT  Class  Definitions 
% - 


var  Table 
var  StateTable 
var  StateEntry 
var  Identifier 


object-class  subtype-of  user-object 
object-class  subtypo-of  Table 
object-class  subtype-of  Table 
object-class  subtype-of  Table 


- ^ - 

'/,  STT  Attribute  Declarations 
- J - 


Vcir  table-neune 
var  table-label 
var  state-entries 
var  current-state 
var  state-event 
var  state-parameter 
var  state-guard 
var  next-state 


map(Table,  Identifier)  =  fll} 
map(Table,  Identifier)  =  {l|} 
map(Table,  seq(StateEntry) )  =  {||} 
map(Table,  Identifier)  =  {| 1} 
map(Table,  Identifier)  =  {||} 
map(Table,  seq(Identif ier) )  =  {| 1} 
map(Table,  Identifier)  =  {| 1} 
map(Table,  Identifier)  =  {I  1} 
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var  state-action 
var  niun-real 
var  num-int 


:  mapdable.  Identifier)  =  {ll} 
:  map(Table,  real)  =  {||} 

:  mapdable,  integer)  =  {||} 


5^ - ^ - 

*/,  Structure  for  Abstract  Syntax  Tree 
- 


form  Define-Tree-Attributes-of -State-Table 

Def ine-Tree-Attributes( 'StateTable,  {’table -name,  ’table-label,  ’ state-entries})& 
Def ine-Tree-Attributes( ’StateEntry,  {’current-state,  ’state-event,  ’state-parameter, 

’state-guard,  ’next-state,  ’state-action}) 


5^ - 

'/,  STT  Grammar  Definition 
^ - 


! ! in-grammar ( ’ syntax) 
grcunmax  STT 

start-classes  StateTable 
file-classes  StateTable 
no-patterns 

case-sensitive 
symbol-cont inue-chars 

"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMN0PQRSTUVWXYZ0123456789._-=\\$()<>" 

symbol-start-chcirs 

"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMN0PQRSTUVWXYZ0123456789_$(" 

productions 

StateTable  ::=  C"\\begin{table}[htb] " 

"\\caption{"  table-name  "}" 

"\\vspace*{ . 2in}" 

"\\label{"  table-label  ">" 

"Wcentering" 

"\\begin{tabular}{ 1 1 1 1 1 1 1 1 1 1 1 1 1 1 }" 

"Whline" 

"Current"  "&"  "Event"  "Peirameters"  "&"  "Guard"  "ft" 

"Next"  "ft"  "ActionWW" 

"  WhlineWhl  ine  " 
state-entries  +  "" 

"WhlineWhl  ine" 

"Wend{tabular}" 

"Wend{table}"]  builds  StateTable, 

StateEntry  ::=  [current-state  "ft"  state-event  "ft"  state-parameter  *  "" 

"ft"  {state-guard}  "ft"  next-state  "ft"  {state-action} 
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"\\\\"  {"Whline"}]  builds  StateEntry, 

Identifier  : :=  [(name  I  num-int  I  num-real)]  builds  identifier 

end 
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Appendix  E.  Unified  Domain  Model 


This  appendix  contains  the  object-oriented  domain  models  for  the  unified  abstract 
framework.  These  models  identify  the  common  object  classes  shared  by  Larch  and  Z.  The 
common  object  classes  promote  a  uniform  interface  for  formalizing  object-oriented  anal¬ 
ysis  models  and  are  the  foundation  for  establishing  a  canonical  representation  for  formal 
specification  languages.  Each  language’s  “dialect”  (i.e.,  the  variances  of  the  language  from 
the  common  core)  is  depicted  in  the  figures  as  specialized  object  classes. 


Figure  E.l  Unified  Domain  Theory  Model 


Figure  E.2  Unified  Object  Theory  Body 
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Figure  E.3  Unified  Dynamic  Theory  Body 
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Figure  E.4  Unified  Functional  Theory  Body 
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CURRENT 


Figure  E.5  State  Transition  Table 
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Appendix  F.  REFINE  Code  for  the  Unified  Domain  Model 


This  appendix  contains  the  Refine  code  for  the  unified  abstract  framework  depicted 
in  Appendix  E.  This  code  demonstrates  the  object-based  nature  of  the  Refine  specifi¬ 
cation  language.  The  objects  and  attributes  specified  in  Refine  are  modular  and  easily 
extensible  using  the  notion  of  subclasses  and  tree-attributes.  The  flexibility  of  this  specifi¬ 
cation  language  makes  future  enhancements  to  the  unified  abstract  model  straightforward. 


! !  in-package ("RU") 

!!  in-grammar ( 'user) 

#1  I 

File  name:  unif ied-dm.re 

Description:  The  following  specification  defines  the  Unified  Domain 
Model  objects,  attributes,  and  syntax  tree.  The  unified  domain  model 
was  constructed  by  analyzing  the  separate  abstract  syntax  trees  (AST) 
of  Larch  and  Z. 

II# 

I - 

'/.  Unified  Domain  Model  Object  Class  Definitions 

•/^ - - 


var  Unif ied-Object 


:  object-class  subtype-of  user-object 


var  DomainTheory 


:  object-class  subtype-of  Unif ied-Object 


var  DomainTheoryTypes 
var  ObjectTheory 
Vcir  DynamicTheory 
var  FunctionalTheory 


:  object-class  subtype-of 
:  object-class  subtype-of 
:  object-class  subtype-of 
:  object-class  subtype-of 


Unif ied-Ob j  ect 
DomainTheoryTypes 
DomainTheoryTypes 
DomainTheoryTypes 


var  Theoryld 

var  ObjectTheoryld 
var  DynamicTheoryld 
var  FunctionalTheoryld 


:  object-class  subtype-of 
:  object-class  subtype-of 
:  object-class  subtype-of 
:  object-class  subtype-of 


Unif ied-Object 
Theoryld 
Theoryld 
Theoryld 


var  TheoryBody 

var  ObjectTheoryBody 
var  DynamicTheoryBody 
var  FunctionalTheoryBody 


object-class  subtype-of 
object-class  subtype-of 
object-class  subtype-of 
object-class  subtype-of 


Unif ied-Object 
TheoryBody 
TheoryBody 
TheoryBody 


var  TheoryDecl 

var  ObjectTheoryDecl 
var  DynamicTheoryDecl 


:  object-class  subtype-of  Unif ied-Object 
:  object-class  subtype-of  TheoryDecl 
:  object-class  subtype-of  TheoryDecl 
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var  FunctionalTheoryDecl  :  object-class  subtype-of  TheoryDecl 


var  SignatureDecl 
Vcir  ContextRef 


:  object-class  subtype-ol  Unif ied-Object 
:  object-class  subtype-ol  Unif ied-Object 


var  TheoryAxioms  : 

var  ObjectTheoryAxioms  : 

vax  DynamicTheoryAxioms  ; 

var  FunctionalTheoryAxioms : 


object-class  subtype-of  Unif ied-Object 
object-class  subtype-of  TheoryAxioms 
object-class  subtype-of  TheoryAxioms 
object-class  subtype-of  TheoryAxioms 


5^ - 

*/.  Unified  Model  Attribute  Declarations  for  Branches  in  Tree  Structure 
- 

var  theory-types  :  map(DomainTheory,  set(DomainTheoryTypes)) 

computed-using  theory-types (x)  =  {} 


var  theory-id 
vax  ot-id 
vax  dt-id 
var  ft-id 


:  map(DomainTheoryTypes,  IdName)  =  {| 1} 
:  map(DomainTheoryTypes,  IdName)  =  {| 1} 
:  map(DomainTheoryTypes,  IdName)  =  {11} 
:  map(DomainTheoryTypes,  IdName)  ={11} 


var  theory-body 
Vcir  ot-body 
var  dt-body 
var  ft-body 


:  map(DomainTheoryTypes,  TheoryBody)  =  {]  1} 
:  map(DomainTheoryTypes,  TheoryBody)  =  {11} 
:  map(DomainTheoryTypes,  TheoryBody)  =  {|  1} 
:  map(DomainTheoryTypes,  TheoryBody)  =  {|  1} 


vax  theory-decl  :  map (TheoryBody,  TheoryDecl)  =  {||} 

var  context-refs  :  map(TheoryDecl,  set (ContextRef)) 

computed-using  context-ref s(x)  =  {} 


var  signature-decl 


:  map (TheoryDecl,  set (SignatureDecl)) 
computed-using  signature-decl (x)  =  {} 


var  theory-axioms 


:  map (TheoryBody,  set (TheoryAxioms)) 
computed-using  theory-axioms (x)  =  {} 


5^ - 

'/,  structure  for  Abstract  Syntax  Tree 
- - - 

form  Define-Tree-Attributes-of -Unif ied-Specificat ion 

Def ine-Tree-Attributes( 'DomainTheory,  {’theory-types})ft 
Def ine-Tree-Attributes( 'ObjectTheory,  {'ot-id,  'ot-body})& 

Def ine-Tree-Attributes( 'DynamicTheory,  {’dt-id,  'dt-body})& 

Def ine-Tree- Attributes ( 'FunctionalTheory,  {’ft-id,  ’ft-body})ft 
Def ine-Tree-Attr ibutes ( ’ TheoryBody ,  { ’ theory-decl ,  ’ theory-cixioms}) & 
Define-Tree-Attributes( ’TheoryDecl,  {’signature-decl,  ’context-refs}) 
Define-Tree-Attributes(’TheoryAxioms,  {’/,’/,  fill  in  Larch/Z  specific})* 
*/,'/,  Define-Tree-Attributes(’ContextRef ,  {*/,7,  fill  in  Larch/Z  specific})* 

*/,*/,  Define-Tree-Attributes(’SignatureDecl,  {’/,'/,  fill  in  Larch/Z  specific})* 
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Appendix  G.  ULarch  Domain  Model 


The  Larch  specific  extensions  to  the  unified  abstract  model  are  shown  in  the  fol¬ 
lowing  figures.  These  models  form  the  basis  for  future  semantic  analysis  tasks  to  reduce 
the  language  specific  notations  into  a  canonical  format.  This  task  can  be  accomplished  by 
extending  the  unified  abstract  framework  using  pattern  matching  and  term  rewriting  on 
the  Larch  and  Z  specific  object  classes. 


Figure  G.l  Domain  Model  -  Larch  Signature  Declarations 
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FIELD  NAMES 
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SORT  NAME 

Figure  G.2  Domain  Model  -  Larch  Context  References 
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Figure  G.4  Domain  Model  -  Larch  Enumeration  References 
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l8-quantltied  (FIGURE ) 


SORT  NAME 
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partitioned-by 


OPERATORS 


has_8ort 

has  sort 
c 

Figure  G.5  Domain  Model  -  Larch  Axioms 
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Figure  G.6  Domain  Model  -  Larch  Equations 
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Figure  G.7  Domain  Model  -  Larch  Terms 
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Figure  G.8  Domain  Model  -  Larch  Consequences 
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IteTerm 

::=  [arg-1 

gtTerm 

::=  [arg-1 

gteTerm 

[arg-1 

eqTerm 

[arg-1 

notEqTerm 

::=  [arg-1 

<="  3arg-2]  builds  IteTerm, 

>"  arg-2]  builds  gtTerm, 

>="  arg-2]  builds  gteTerm, 

="  2trg-2]  builds  eqTerm, 

Wneq"  arg-2]  builds  notEqTerm, 


bracket edExpr 

Exprl 

Expr2 

Expr3 

Expr4 


[open-sym  te-rms  *  close-sym  {arg-2]-]  builds  bracketedExpr , 
["("  te-rm  ")"  {[  simpla-id]>]  builds  Exprl, 

[simple-id]  builds  Expr2, 

[simple-id  "("  args  +  ")"  {["."  simple-id2] }]  builds  ExprS, 

[sort-id  field-id]  builds  Expr4, 


UserOp 

Multiply 

Addition 

Subtraction 

Divide 

LessThan 

LessThanEq 

Equality 

GreaterThan 

Great erThanEq 

And-Obj 

Or-Qbj 

Not-Obj 

Implies 

EqualSym 

NotEqual 


=  ["W"  op-id]  builds  UserOp, 

=  ["*"]  builds  Multiply, 

=  ["■*■"]  builds  Addition, 

=  ["-"]  builds  Subtraction, 

=  ["/“]  builds  Divide, 

=  ["<"]  builds  LessThcin, 

=  ["<="]  builds  LessThanEq, 

=  ["="]  builds  Equality, 

=  [">"]  builds  GreaterThan, 

=  [">="]  builds  Great erThanEq, 

=  ["Wand"]  builds  And-Obj  , 

=  ["\\or"]  builds  Or-Obj , 

=  ["■"]  builds  Not-Obj, 

=  ["Wimplies"]  builds  Implies, 
=  ["\\eq"]  builds  EqualSym, 

=  ["Wneq"]  builds  NotEqual, 


Consequences  Part 

Consequencesl  ::=  ["implies"  {["("  traitref  +  ","  ")"]> 

{conseq-part}  {con-version}]  builds  Consequencesl, 
ConseqPartl  ::=  [gen-Peirtitions  +  ""  eq-uations2  ";"]  builds  ConseqPartl, 


ConseqPart2 


[gen-Partitions  *  ""  eq-pcr-t2]  builds  ConseqPart2, 


Conversion  ::=  ["converts"  op-erators  +  ","  {ex-empting}]  builds  Conversion, 

Exempting  :;=  ["exempting"  {qu-aintif ier}  te-rms  +  ","]  builds  Exempting 


keyword-alt  emat  ives 

"/W"  may-replace  "Weind", 
"W/"  may-replace  "Wor", 

"=>"  may-replace  "Wimplies", 
"Wlangle"  may-replace  "W<", 
"Wrangle"  may-replace  "W>", 
"Wgeq"  may-replace  ">=" , 
"Wleq"  may-replace  "<=", 
"Wequals"  may-replace  "==", 
"Weqsep"  may-replace 
"Warrow"  may-replace  "->" 
end 
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Appendix  J.  Semantic  Analysis  Code 


The  following  Refine  program  traverses  a  ULarch  abstract  syntax  tree  (AST)  and 
augments  the  AST  with  any  included  traits  by  unioning  the  signatures  and  the  axioms  of 
the  included  trait  with  the  trait  doing  the  inclusion.  The  end  result  is  an  expanded  AST 
that  defines  all  of  a  specification’s  appropriate  signatures  and  axioms.  This  expanded  AST 
simplifies  the  semantic  analysis  and  code  generation  tasks. 


!  !  in-package ("RU") 
!!  in-grammar ( 'user) 


#1  I 

File  name:  includes. re 

I  I# 

! !  in-package ("RU") 

!!  in-grammar ( 'user) 

function  make-includes-link  ()  = 

let  (Temp-Op-Decl  :  OpDecl  =  make-object ('OpDecl)) 
let  (specs  :  set(DomainTheoryTypes)  = 

instances(f ind-object-class('DomainTheoryTypes) ,  true)) 
let  (Temp-Symbol  :  Symbol  =  newsymboK 'TempSymbol)) 
let  (Temp-Theory-Axiom  :  TheoryAxioms  =  make-object( 'TheoryAxioms)) 
let  (Temp-Tuple-Obj  :  Tuple-Obj  =  make-object( 'Tuple-Obj)) 

(enumerate  tr  over  specs  do 

(enumerate  i  over  descendants-of-class(theory-body(tr) ,  'Includes)  do 
(enumerate  j  over  descendants-of-class(i,  'IdName)  do 
(Temp-Symbol  <-  name(j); 
enumerate  k  over  specs  do 

(if  (Temp-Symbol  =  name(theory-id(k) ) )  then 
(enumerate  1  over  descendants-of-class(theory-body(k) ,  'OpDecl)  do 
(Temp-Op-Decl  <-  1; 

op-decls(signature-decl(theory-decl(theory-body(tr))))  <- 
op-decls (signatur e-decl(theory-decl (theory-body (tr) ) ) )  with  Temp-Op-Decl 
) 

); 

(enumerate  m  over  descendants-of-class(theory-body(k) ,  'TheoryAxioms)  do 
(Temp-Theory-Axiom  <-  m; 

theory-axioms (theory-body (tr))  <-  theory-axioms (theory-body (tr))  with 
Temp-Theory-Axiom 
) 

); 

(enumerate  n  over  descendants-of-class(theory-body(k) ,  'Tuple-Obj)  do 
(Temp-Tuple-Obj  <-  n; 
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coiitext-rels(theory-decl (theory-body (tr)))  <- 
context-ref s(theory-decl(theory-body(tr)))  with  Temp-Tuple-Dbj 
) 

) 

) 

) 

) 

) 

) 
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Appendix  K.  Target  Domain  Model 

This  appendix  contains  the  object-oriented  domain  model  for  the  execution  frame¬ 
work.  Refine  is  the  target  framework,  and  the  following  figures  identify  the  principal 
object  classes.  This  model  guides  the  development  of  the  execution  framework  mappings 
providing  a  concrete  target  for  the  source  objects. 


Figure  K.l  Unified  Domain  Theory  Model  -  1 
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Figure  K.2  Unified  Domain  Theory  Model  -  2 


Appendix  L.  REFINE  Code  for  the  Target  Domain  Model 


The  following  Refine  specification  defines  the  object  classes  and  map  attributes  for 
the  execution  framework.  Because  the  target  execution  framework  is  Refine,  the  code 
incorporates  the  notions  of  object  classes,  map  attributes,  functions,  and  rules,  as  the 
target  objects. 


! !  in-package ("RU") 

!!  in-grammar ( ’user) 

#1  I 

File  name:  exec. re 

I  I# 

^ - 

*/,  Refine  Object  Class  Declaration 
- 


var  Refine-Object-Model 
var  Refine-Declaration 


:  object-class  subtype-of  user-object 
:  object-class  subtype-of  Refine-Object-Model 


var  Ref ine-Decl-Attrs 

var  Ref ine-Annotation-Attr 
var  Ref ine-Tree-Attr 
var  Ref ine-Decl-Obj -Class 


;  object-class 
:  object-class 
;  object-class 
:  object-class 


subtype-of 

subtype-of 

subtype-of 

subtype-of 


Ref ine-Ob j  ect-Model 
Ref ine-Decl-Attrs 
Ref ine-Decl-Attrs 
Refine-Object-Model 


var  Refine-Function 
var  Refine-Function-Body 
var  Function-Parameters 
var  Parameter-Value 
var  Pcirameter-Type 
var  Function-Let-Statement 
var  Function-Transform 
var  Function-Precondition 
var  Function-Postcondition 


object-class 
object-class 
object-class 
obj  ect-class 
object-class 
object-class 
object-class 
object-class 
object-class 


subtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 


Ref ine-Ob j  ect-Model 
Refine-Object-Model 
Ref ine-Ob j  ect-Model 
Ref ine-Ob j  ect-Model 
Ref ine-Ob j  ect-Model 
Ref ine-Ob j  ect-Model 
Ref ine-Ob j  ect-Model 
Ref ine-Ob j  ect-Model 
Ref ine-Ob j  ect-Model 


var  Refine-Rule 

var  Rule-Precondition 

var  Rule-Postcondition 


:  object-class 
:  object-class 
:  object-class 


subtype-of  Refine-Object-Model 
subtype-of  Refine-Object-Model 
subtype-of  Refine-Object-Model 


% - 

'/,  Refine  Attribute  Declarations  for  Branches  in  Tree  Structure 
- 

var  refineDecl  :  map(Ref ine-Ob j ect-Model,  Refine-Declaration)  =  {| 1} 

var  ref ineObjClasses  :  map(Ref ine-Object-Model,  set(Ref ine-Decl-Obj-Class)) 

computed-using  ref ineObjClasses(x)  =  {} 
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vax  relineAttrs 


:  map(Ref ine-Object-Model,  set(Ref ine-Decl-Attrs)) 
computed-using  relineAttrs(x)  =  {} 


vcir  ref  ineFunct ions 

var  functionBody 
var  parameterList 

var  parameters 

var  parameterType 
var  letStatements 

var  transforms 

var  functionPre 

var  fnnctionPost 


:  map (Refine-Object-Model,  set(Ref ine-Function)) 
computed-using  ref ineFunctions(x)  =  {} 

;  map(Ref ine-Object-Model,  Refine-Function-Body)  =  {11} 
:  map(Ref ine-Object-Model,  set (Function-Parameters)) 
computed-using  parameterList(x)  =  {} 

:  map(Function-Parameters ,  set (Parameter-Value) ) 
computed-using  parameters (x)  =  {} 

;  map(Function-Pcirameters ,  Parameter-Type)  =  {| 1} 

:  map(Ref ine-Object-Model,  set (Function-Let-Statement)) 
computed-using  letStatements (x)  =  {} 

:  map (Ref ine-Object-Model,  set (Function-Transform)) 
computed-using  transforms (x)  =  {} 

:  map(Ref ine-Object-Model,  set (Function-Precondition)) 
computed-using  functionPre (x)  =  {} 

:  map(Ref ine-Object-Model,  set (Function-Postcondition)) 
computed-using  functionPost(x)  =  {} 


var  refineRules  :  map(Ref ine-Object-Model,  set (Refine-Rule)) 

computed-using  ref ineRules(x)  =  {} 

var  rulePre  :  map(Ref ine-Object-Model,  set (Rule-Precondition) ) 

computed-using  rulePre(x)  =  {} 

var  rulePost  :  map(Ref ine-Object-Model,  set (Rule-Postcondition)) 

computed-using  rulePost (x)  =  {} 


^ - 

'/,  Annotation  Attributes 

5^ - 

For  Object  Ref  ine-Decl-Attrs 

Vcir  attrDomain  :  map(Ref ine-Decl-Attrs,  symbol)  =  {| 1} 

var  attrCoDomain  :  map(Ref ine-Decl-Attrs ,  symbol)  =  {| 1} 


- 

*/,  Declarations  for  other  Objects 
% - 


var  Exec-Program  ;  Ref ine-Object-Model  =  make-object( 'Refine-Object-Model) 


% - 

*/,  Structure  for  Abstract  Syntax  Tree 
- ^ - 


form  Def ine-Tree-Attributes-of-Ref ine-Rules 

Def ine-Tree-Attributes( 'Ref ine-Object-Hodel,  {'ref ineDecl,  'ref ineFunct ions , 
'ref ineRules})& 

Def ine-Tree-Attributes( 'Ref ine-Declaration,  {'ref ineObjClasses , 

'ref ineAttrs})& 

Def ine-Tree-Attributes( 'Ref ine-Function,  {'parameterList ,  'functionBody})* 
Define-Tree-Attributes(' Function-Parameters,  {'parameters,  'parameterType})* 
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Def ine-Tree-Attr ibutes ( ’ Ref ine-Funct ion-Body ,  { ’ letStat ement s , 
'transforms})* 

Def ine-Tree-Attributes( 'Fnnction-Trcinsform,  {’functionPre,  ’functionPost})* 
Def ine-Tree-Attributes( 'Ref ine-Rule,  {’rulePre,  'rulePost}) 
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Appendix  M.  REFINE  Code  for  the  Initial  Execution  Code 


The  following  Refine  program  creates  an  initial  framework  for  an  executable  pro¬ 
gram.  The  main  function,  Make- Executable,  encapsulates  the  Make-Object-Classes,  Make- 
Attributes,  and  Make-Function  operations  generating  the  appropriate  object  classes  and 
attributes  in  the  execution  framework  from  the  source  objects.  After  creating  the  execu¬ 
tion  framework,  the  Print-Program  function  traverses  the  executable  AST  and  prints  an 
executable  program’s  initial  shell  consisting  of  the  object  classes,  map  attributes,  function 
names,  and  parameters. 


! !  in-package ("RU") 

!!  in-graimnar( 'user) 

#1  I 

File  name:  transform. re 

II# 

function  Make-Object-Class  (Temp-Specs  :  set(DomainTheoryTypes) , 

Temp-Decl  :  Refine-Declaration, 

Temp-Exec-Progreun  :  Refine-Object-Model)  :  Refine-Object-Model  = 

let  (Refine-Object  :  Ref ine-Decl-Obj-Class  =  make-object( 'Ref ine-Decl-Obj-Class)) 

(enumerate  tr  over  Temp-Specs  do 
(enumerate  o  over  descendants-of-class(tr ,  'ObjectTheory)  do 
Refine-Object  <-  set-attrs(make-object( 'Ref ine-Decl-Obj-Class) , 

'Name,  name(theory-id(o) )) ; 

(format  (true,  "Refine-Object  'a*5i",  Refine-Object)); 

ref ineObjClasses(Temp-Decl)  <-  ref ineObjClasses(Temp-Decl)  with 

Refine-Object; 

(format  (true,  "programDecl  "a'/t",  Temp-Decl)) 

) 

): 

ref ineDecl (Temp-Exec-Program)  <-  Temp-Decl 


function  Make-Attributes  (Temp-Specs  :  set(DomainTheoryTypes) , 

Temp-Decl  ;  Ref ine-Declciration, 

Temp-Exec-Program  :  Refine-Object-Model)  :  Refine-Object-Model  = 

let  (Refine-Attr  :  Ref ine-Decl-Attrs  =  make-object('Refine-Decl-Attrs)) 

(enumerate  tr  over  Temp-Specs  do 
(enumerate  o  over  descendants-of-class(tr,  'ObjectTheory)  do 
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(enumerate  a  over  descendants-of-class{o ,  'Tuple-Obj)  do 
(enumerate  f  over  descendants-of-class(a,  ’Field)  do 
(enumerate  ii  over  lield-ids(f)  do 

Refine-Attr  <-  set-attrs(make-object(’Refine-Decl-Attrs) , 
'Name,  name(li), 

'attrDomain,  name(theory-id(tr) ) , 

’attrCoDomain,  name(sort-id(f))) ; 

(format  (true,  "Refine-Attr  'a"%",  Refine-Attr)); 
ref ineAttrs(Temp-Decl)  <-  ref ineAttrs(Temp-Decl)  with 
Refine-Attr; 

(format  (true,  "programDecl  "a**/",  Temp-Decl)) 

) 

) 

) 

) 

): 

ref ineDecl (Temp-Exec-Program)  <-  Temp-Decl; 

(format  (true,  "Exec-Program  *a'*/.",  Temp-Exec-Program)) 


function  Make-Function  (Temp-Specs  :  set(DomainTheoryTypes) , 

Temp-Exec-Program  ;  Refine-Object-Model)  :  Refine-Object-Model  = 


let  (Temp-Function 
let  (Temp-Set 
let  (Temp-Psiram 
let  (Temp-Param-Set 
let  (Temp-Param-List 


Refine-Function  =  make-object(’Refine-Function)) 
set (Refine-Function)  =  {}) 

Parameter-Value  =  make-object( ’Parameter-Value)) 
set  (Parameter-Value)  =  {]•) 
set (Function-Parameters)  =  {}) 


(enumerate  tr  over  Temp-Specs  do 

(enumerate  d  over  descendants-of-class(tr ,  ’DomainTheoryTypes)  do 
(enumerate  e  over  descendants-of-class(d,  ’OpDecl)  do 
(enumerate  f  over  descendants-of-class(e,  ’NeuneObj)  do 
if  def ined?(op-id(f ))  then 

Temp-Function  <-  set-attrs(make-object( ’Ref ine-Function) , 
’Name,  name(op-id(f ) ) ) ; 

format(true,  "Temp-Function  'a"*/(",  Temp-Function); 
if  empty (Temp-Set)  then 

(Temp-Set  <-  Temp-Set  with  Temp-Function 

) 

else 

(enumerate  g  over  Temp-Set  do 
if  name(g)  "=  name (Temp-Function)  then 
Temp-Function 

else 

Temp-Function  <-  undefined 

); 

if  def ined? (Temp-Function)  then 

Temp-Set  <-  Temp-Set  with  Temp-Function 

): 

(enumerate  s  over  descendants-of-class(e,  ’SortSet)  do 
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(format(true,  "in  SortSet 
enumerate  d  over  domain-ids (s)  do 
Temp-Param  <-  d; 

format  (true,  "temp-param  is  "a**/,",  Temp-Param); 
if  empty(Temp-Param-Set)  then 

Temp-Param-Set  <-  Temp-Param-Set  with  Temp-Param 
else 

(enumerate  x  over  Temp-Param-Set  do 
if  name(x)  "=  name(Temp-Param)  then 
Temp-Par am 
else 

Temp-Pareim  <-  undefined 

); 

if  defined? (Temp-Param)  then 

Temp-Param-Set  <-  Temp-Param-Set  with  Temp-Param 

) 

) 

) 

) 

): 

ref ineFunct ions (Temp-Exec-Program)  <-  ref ineFunctions(Temp-Exec-Progrcim)  union  Temp-Set 
(format  (true,  "Exec-Program  "a"%",  Temp-Exec-Program)) 


function  Make-Executable  (theory  :  DomainTheory)  :  Refine-Object-Model  = 
let  (Specs  ;  set(DomainTheoryTypes)  =  {}) 

let  (Temp-Exec-Program  ;  Ref ine-Object -Model  =  make-object( 'Ref ine-Object-Model) ) 
let  (Program-Decl  :  Refine-Declaration  =  mcike-object('Refine-Declaration)) 

(enumerate  s  over  descendants-of-class (theory ,  ’DomainTheoryTypes)  do 
Specs  <-  Specs  with  s 
); 

(Make-Object-Class (Specs,  Program-Decl,  Temp-Exec-Progreun) ) ; 

(Make-Attributes (Specs,  Program-Decl,  Temp-Exec-Program)); 

(Make-F;mction(Specs ,  Temp-Exec-Program) ) 

function  Print-Program  (Program  :  object)  = 

undefined? (Program)  — >  format(true,  "Nothing  to  print  "'/,"); 
defined? (Program)  — > 

format  (true,  "J  !  in-package (RU)  '%"); 
format  (true,  "!!  in-grammar ( 'user)  "/,  *’/,  '*/,"); 

(eniunerate  d  over  descendeints-of-class (Program,  'Refine-Declaration)  do 
(enumerate  o  over  descendants-of-class(d,  'Ref ine-Decl-Obj-Class)  do 

format  (true,  "'/. - 'A - '/,  name(o)); 

format  (true,  "'/, - '/•  *'/."); 

format  (true,  "var  "A  :  object-class  subtype-of  user-object 
name(o)) ; 

format  (true,  "  "/.") 

): 
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(enumerate  a  over  descendants-of-class(d,  'Ref ine-Decl-Attrs)  do 

format(true,  "var  "A  :  mapCA,  "A)  =  {|  |}  "7,",  name(a),  attrDomain(a) , 
attrCoDomain(a) ) ; 
format  (true,  "  "7,") 

) 

): 

(enumerate  e  over  descendants-of-class(Progrcim,  ’Refine-Function)  do 
format(true,  "function  "A  ()  =  "7",  name(e)) 

) 
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Appendix  N.  User’s  Manual  for  the  Unified  Larch  Parser 


This  appendix  contains  a  listing  of  the  REFINE  files  required  to  parse  Larch  traits. 
The  order  in  which  the  files  are  listed  below  indicates  the  required  compilation  order. 
Following  the  file  listings  is  a  set  of  instructions  guiding  a  user  through  a  sample  session  for 
parsing  Larch  traits  and  viewing  the  corresponding  AST.  In  addition,  the  final  instruction 
shows  the  user  how  to  create  an  execution  framework  for  the  parsed  Larch  traits. 


1.  Load  system  files  for  Dialect  and  Object  Inspector. 

(load  ‘ ‘load- inspector’ ’ ) 

(load-inspector) 

2.  Load  the  unified  {\sc  Larch}  domain  model  eind  grammar  files  and 
the  target  execution  domain  model.  Bring  the  unified  {\sc  Larch} 
grammar  in  the  environment . 

(load  ‘ ‘ularch-dm’ ’ ) 

(load  ‘ ‘ularch-gram’ ’ ) 

(in-grammar  ’ularch) 

(load  ‘ ‘exec’ ’) 


3.  Load  the  semantic  analysis  file, 
(load  ‘ ‘ includes .fasl4’ ’ ) 


4.  Load  the  translation  program. 

(load  ‘ ‘transform.f asl4’ ’ ) 

5.  Parse  your  domain  specification. 

*/,  C-x-i  "/research/demo/fueltank_domain/ut/combined.ut  (for  fuel  tank  domain) 

'/,  C-x-i  "/research/demo/counter_domain/ref ine/ucounter .re  (for  counter  domain) 


6.  View  the  initial  domain  specification  using  {\sc  Object  Inspector}. 

(pup)  '/i  returns  the  magic  object  number 

(insp:  :  inspect  (men  <object’s  magic-number>) )  '/,  brings  {\sc  Object  Inspector} 

*/,  up  with  the  current  object. 

7,'/,  for  demo  view  a  functional  trait  from  the  Counter  and  Fuel  Tank  Domains 
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7.  Execute  ‘ ‘make-includes-link’ ’  on  your  domain  specification 
to  bring  in  all  referenced  specifications. 

(make-includes-link (men  <object’s  magic-number>) ) 

8.  View  the  augmented  AST  using  {\sc  Object  Inspector}. 

(insp: :inspect-obj (men  <object’s  magic-number>) ) 

*/,'/,  for  demo  view  a  functional  trait  from  the  Counter  and  Fuel  Tank  Domains 

9.  Execute  the  translation  function. 

(make-executable (men  <domaintheory  object’s  magic  number>)) 

(print-program  (men  <executable  object’s  magic  number>)) 

10.  Example  of  Demonstration  Sequence 

a.  load  the  counter  domain  */,  C-x-i  "/research/demo/counter_domain/ref ine/ucounter .r« 

b .  parse  the  domain  theory 

c.  show  the  domain’s  AST  */,  (pup)  to  get  domain  theory’s  object  number 

*/,  (insp: :  inspect  (men  <object’s  magic-number>) ) 

d.  perform  short -hand  expansion  */,  (make-includes-link) 

e.  perform  execution  translation  '/.  (make-executable) 

f.  print  executable  shell  '/,  (print-program  (men  <executable  object’s 

magic  number>)) 

g.  other  test  domains:  fuel  tank  and  SimpleGraph.re 

*/,  file  location  ("/research/ demo/fueltank_domain/ut/combined.ut) 
y,  file  location  ( "/research/ demo/lsl/test/SimpleGraph. re) 
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Appendix  O.  Validation  Specifications 


This  appendix  contains  the  sample  set  of  MIT  traits  that  have  been  parsed  success¬ 
fully.  In  addition,  Major  Scott  Deloach’s  graph  theory  has  been  parsed  and  is  included 
here.  Parsing  these  traits  demonstrates  that  the  parser  can  handle  a  wide-range  of  Larch 
specifications.  Note  the  placement  of  parentheses  for  compound  terms  in  the  algebraic 
equations.  These  parentheses  are  necessary  to  reduce  the  ambiguity  during  parsing. 


0.1  MIT  Sample  Traits 

‘/.ObjectTheory 

ListStructure(A,  E,  C) :  trait 
includes  List 

E  union  of  list:  C,  atom:  A 


'/.ObjectTheory 
PQueue  (E,  Q) :  trait 
assumes  TotalOrder  (E) 
includes  Container(Q  for  C) 
asserts  V  e,  el:  E,  q:  Q 
head(insert(e,  q))  == 

if  isEmpty(q)  V  (e  >  head(q)) 
then  e  else  head(q) ; 
tail(insert(e,  q))  == 

if  isEmpty(q)  V  (e  >  head(q)) 
then  q  else  insert(e,  tail(q)) 
implies 

V  q:  q,  e:  E 

(e  €  q)  ->  (e  <  head(q)) 
converts  head,  tail,  isEmpty,  count,  6 
exempting  head(empty),  tail(empty) 

'/.ObjectTheory 
PairwiseSum(C) :  trait 

assumes  Container(Iht ,  C) 

includes  Integer,  PairwiseExtension(+,  0,  Int,  C) 
implies  (Associative(©,  C) , 

CommutativeC©  for  o,  C  for  T,  C  for  Range)) 

0.2  Graph  Theory^ 

'/.ObjectTheory 

SimpleGraph  (E,  V,  G) :  trait 

^This  theory  was  written  by  Major  Scott  Deloach. 
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G  tuple  of  V  :  VSet,  e  :  ESet 
includes  Set(V  for  E,  VSet  for  C) 
includes  Set(E  for  E,  ESet  for  C) 

E  tuple  of  vl:  V,  v2  :  V 
includes  GraphRelation  (E,  V,  G,  R) 
assumes  Symmetric (R) 

introduces 

vertices:  G  — >■  VSet 
edges:  G  — *•  ESet 

complete,  forest,  existsCircuit ,  noLoops,  existsLoops, 

tree,  connected:  G  — +  Bool 

subgraph:  G,  G  — »■  Bool 

endVertex:  V,  G  ^  Bool 

adjacent,  exist sPath:  V,  V,  G  — +  Bool 

insertVertex:  V,  G  — *■  G 

insertEdge:  V,  V,  G  — >■  G 

numEdges,  numVertices:  G  — *■  Int 

degree:  V,  G  — +  Int 

asserts  V  v,  vl,  v2:  V,  g,  gl:  G 
vertices(g)  ==  g.v; 
edges (g)  ==  g.e; 

endVertex(v,  g)  ==  ((([v,  vl])  €  g.e)  A  (([v,  v2])  e  g.e))  =$•  (vl  =  v2) 
adjacent (vl,  v2,  g)  ==  ([vl,  v2])  €  g.e; 
existsPath(vl ,  v2,  g)  ==  vl  {  (R(g)*)  )  v2; 

connected(g)  ==  ((vl  €  g.v)  A  (v2  €  g.v))  (existsPath(vl ,  v2,  g)); 

complete(g)  ==  ((vl  €  g.v)  A  (v2  €  g.v))  =»  (([vl,  v2])  €  g.e); 

forest(g)  ==  (vl  €  g.v)  =>  ( -i  (vl  (  (R(g)+)  )  vl)); 

existsCircuit (g)  ==  -i  forest(g); 

noLoops(g)  ==  (v  e  g.v)  =>  (([v,  v])  ^  g.e); 

existsLoops (g)  ==  -i  noLoops(g); 

tree(g)  ==  existsPath(vl ,  v2,  g)  A  forest(g); 

subgraph(gl,  g)  ==  (([vl,  v2])  G  gl.e)  (([vl,  v2])  £  g.e); 

ins ert Vert ex(v,  g)  ==  [(g.v  U  ({v»),  g.e]; 

insertEdge (vl ,  v2,  g)  ==  [g.v,  (g.e  U  (({[vl,  v2]})  U  ({[v2,  vl]>)))]; 

numEdges(g)  ==  div(size(g. e) ,  2); 
numVertices (g)  ==  size(g.v); 

degree(v,  g)  ==  size(rangeRestrict(R(g) ,  [v,  v])) 
implies 

V  V,  vl,  v2:  V,  gl,  g:  G 
vertices(  [{},  {}])  ==  {}; 
adjacent(vl,  v2,  ([{},  {}]))  ==  false; 
existsPath(vl ,  v2,  ([{},  {}]))  ==  false; 
connected( [{},  {}])  ==  true; 
complete ( [{},  {}])  ==  true; 
forest ([{},  {>])  ==  true; 
existsLoops ([{},  {}])  ==  false; 
existsCircuit ([{},  {}])  ==  false; 
noLoops ( [{ } ,  { }] )  ==  true ; 
tree([{},  {}])  ==  true; 
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subgraphC [{},  {>],  g)  ==  true; 

insertEdgeCvl,  v2,  [{},  {}])  ==  [(({vl})  U  ({v2})),  (({[vl,  v2]})  U  ({Cv2.  vl]»)]: 
insertVertex(v,  ([{},  {}]))  ==  [({v}),  {>]; 
numEdgesC  [{},  {}])  ==  0; 
numVefticesC [{},  {}])  ==  0; 

vertices(insertEdge(vl ,  v2,  g))  ==  g.v  U  (({vl})  U  ({v2})); 
adjacent(vl ,  v2,  insertEdge(vl ,  v2,  g))  ==  true; 
existsPath(vl ,  v2,  insertEdge(vl ,  v2,  g))  ==  true; 
connected(iiisertEdge(vl,  v2,  g))  == 

connected(g)  A  ((vl  G  g-v)  V  (v2  G  g.v)); 
complete ( insertEdge (vl ,  v2,  g))  ==  (vl  G  g.v)  A  (v2  G  g.v); 
forest(insertEdge(vl ,  v2,  g))  ^  ( -i  existsCircuit(g)) ; 
noLoops(insertEdge(vl,  v2,  g))  ==  noLoops(g)  A  (vl  ^  v2)  ; 
existsLoops(insertEdge(vl ,  v2,  g))  ==  existsLoops(g)  V  (vl  =  v2) ; 

tree(insertEdge(vl ,  v2,  g))  ^  (-1  (existsCircuit(g)  A  (-1  tree(g)))); 
subgraph(gl,  insertEdge (vl ,  v2,  g))  ==  subgraph(gl,  g) ; 

subgraph( insertEdge (vl,  v2,  gl),  g)  ==  subgraph(gl,  g)  A  (([vl,  v2])  G  g.e); 
insertEdge (vl,  v2,  insertEdge(vl ,  v2,  g))  ==  insertEdge (vl ,  v2,  g) ; 
numEdges ( insertEdge (vl ,  v2,  g))  ==  if  (([vl,  v2])  G  g.e) 

then  numEdges (g)  else  numEdges (g)  +  1; 
numVertices(insertEdge(vl ,  v2,  g))  ==  numVertices(g)  + 

(((if  vl  G  g.v  then  0  else  1))  + 

((if  v2  G  g.v  then  0  else  1))); 
degree(v,  insertEdge (vl ,  v2,  g))  ==  degree(v,  g)  + 

(if  ((v  =  vl)  A  (v  =  v2))  then  2 
else  (if  ((v  =  vl)  V  (v  =  v2))  then  1 
else  0)); 

vertices (insertVertex(v,  g))  ==  g.v  U  ({v}) ; 
adjacent(vl,  v2,  insertVertex(v,  g))  ==  adjacent(vl,  v2,  g) ; 
connected(insertVertex(v,  g))  ==  connected(g)  A  (v  G  g.v); 
complete(insertVertex(v,  g))  ==  complete(g)  A  (v  G  g.v); 
forest (insertVertex(v,  g))  ==  forest(g); 
noLoops(insertVertex(v,  g))  ==  noLoops(g); 
existsLoops(insertVertex(v,  g))  ==  existsLoops(g) ; 

tree(insertVertex(v,  g))  ==  tree(g)  A  (v  G  g.v); 
subgraph(gl,  insertVertex(v,  g))  ==  subgraph(gl,  g) 

V  subgraph(([(gl.v  -  ({v})),  g.e]),  g) ; 

insertEdge (vl,  v2,  insertVertex(v,  g))  ==  insertVertex(v,  insertEdge (vl ,  v2,  g)); 
numEdges(insertyertex(v,  g))  ==  numEdges(g); 

numVertices(insertVertex(v,  g))  ==  if  v  G  g.v  then  numVertices(g) 

else  numVertices(g)  +  1; 

degree(vl,  insertVertex(v,  g))  ==  degree(vl,  g) ; 

(connected(g)  A  ((vl  G  g.v)  A  (v2  G  g.v))) 
existsPath(vl ,  v2,  g); 

(complete(g)  A  ((vl  G  g.v)  A  (v2  G  g.v))) 

=>  adjacent (vl,  v2,  g); 

(tree(g)  A  ((vl  G  g.v)  A  (v2  G  g.v))) 

=>■  existsPath(vl,  v2,  g) ; 

(tree(g)  A  (((vl  G  g.v)  A  (v2  G  g.v)) 

A  ( -1  adjacent (vl,  v2,  g)))) 
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=>•  existsCirctiit(insertEd.ge(vl ,  v2,  g)); 
tree(g)  =?>•  ( -i  existsCircuit(g)) ; 
tree(g)  (numEdges(g)  =  (iiumVertices(g)  -  1)); 
tree(g)  =>  connectedCg) ; 

((degree(v,  g)  >  2)  A  (v  6  g.v))  existsCircuit(g) ; 

complete(g)  =>  (numEdges(g)  =  ((niiinVertices(g)  *  (numVertices(g)  -  1))  /  2)) 
endVertexCv,  g)  ==  (degree(v,  g)  =  1); 
existsLoops(g)  existsCircuit(g) 
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Appendix  H.  REFINE  Code  for  the  ULaRCH  Domain  Model 

The  following  Refine  specification  defines  the  Larch  Extensions  to  the  Unified  Do¬ 
main  Model.  The  original  Larch  domain  model  was  revised  to  use  the  core  unified  domain 
model  object  classes  and  map  attributes.  The  Larch  extensions  include  Larch  specific  syn¬ 
tax  that  are  specializations  of  a  unified  parent  object  class  found  in  the  Unified  Domain 
Model. 

! !  in-package ("RU") 

!!  in-grcumnar ( ’user) 

#1  I 

File  name:  ularch-dm . re 

I  I# 

% - 

*/,  Unified  Domain  Model  Object  Class  Definitions 

X - 

var  Unif ied-Object  :  object-class  subtype-of  user-object 

var  DomainTheory  :  object-class  subtype-of  Unif ied-Object 

var  DomainTheoryTypes  :  object-class  subtype-of  Unif ied-Object 

var  ObjectTheory  :  object-class  subtype-of  DomainTheoryTypes 

var  DynamicTheory  :  object-class  subtype-of  DomainTheoryTypes 

var  FunctionalTheory  :  object-class  subtype-of  DomainTheoryTypes 

var  Theoryld  :  object-class  subtype-of  Unif ied-Object 

var  ObjectTheoryld  :  object-class  subtype-of  Theoryld 

var  DynamicTheoryld  :  object-class  subtype-of  Theoryld 

var  FunctionalTheoryld  :  object-class  subtype-of  Theoryld 

var  TheoryBody  :  object-class  subtype-of  Unif ied-Object 

Vcir  ObjectTheoryBody  :  object-class  subtype-of  TheoryBody 

var  DynamicTheoryBody  :  object-class  subtype-of  TheoryBody 

var  FunctionalTheoryBody  :  object-class  subtype-of  TheoryBody 

var  TheoryDecl  :  object-class  subtype-of  Unif ied-Object 

var  ObjectTheoryDecl  :  object-class  subtype-of  TheoryDecl 

var  DynamicTheoryDecl  :  object-class  subtype-of  TheoryDecl 

var  FunctionalTheoryDecl  :  object-class  subtype-of  TheoryDecl 

var  SignatureDecl  :  object-class  subtype-of  Unif ied-Object 

var  ContextRef  :  object-class  subtype-of  Unif ied-Object 
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var  TheoryAxioms  :  object-class  subtype-ol  Unif ied-Object 

var  ObjectTheoryAxioms  :  object-class  subtype-of  TheoryAxioms 

var  DynamicTheoryAxioms  :  object-class  subtype-oi  TheoryAxioms 

var  FunctionalTheoryAxioms :  object-class  subtype-of  TheoryAxioms 


- 

'/,  Larch  Specific  Class  Objects 

'/,  The  following  object  classes  are  specilizations  of  the  Unified 
*/,  Domain  model  and  refer  to  the  specific  syntax  of  the  Larch 
’/,  Language.  Specific  identifier  objects  have  been  defined 
*/.  in  order  to  make  the  Refine  program  more  understandable 
*/,  and  more  descriptive. 

^ - 


var  NameObj 

object-class 

subtype-of 

Unif ied-Object 

var  NameObj 1 

object-class 

subtype-of 

NameObj 

var  NameObj 2 

object-class 

subtype-of 

NameObj 

var  OpForm 

object-class 

subtype-of 

Unif ied-Object 

var  OpForm- 1 

object-class 

subtype-of 

OpForm 

var  OpForm-2 

object-class 

subtype-of 

OpForm 

var  OpForm-3 

obj  ect-class 

subtype-of 

OpForm 

var  OpForm-4 

object-class 

subtype-of 

OpForm 

var  OpForm-5 

object-class 

subtype-of 

OpForm 

var  QpForm-6 

object-class 

subtype-of 

OpForm 

var  OpenSym 

object-class 

subtype-of 

Unif ied-Object 

var  OpenSyml 

object-class 

subtype-of 

OpenSym 

var  0penSym2 

object-class 

subtype-of 

OpenSym 

var  OpenSymS 

object-class 

subtype-of 

OpenSym 

var  CloseSym 

object-class 

subtype-of 

Unif ied-Object 

var  CloseSyml 

object-class 

subtype-of 

CloseSym 

Vcir  CloseSyra2 

object-class 

subtype-of 

CloseSym 

var  CloseSymS 

object-class 

subtype-of 

CloseSym 

var  MarkerSym 

obj  ect-class 

subtype-of 

Unif ied-Object 

var  ExternalRef 

object-class 

subtype-of 

ContextRef 

var  Includes 

object-class 

subtype-of 

ExternalRef 

var  Assumes 

object-class 

subtype-of 

ExternalRef 

var  ShorthandRef 

object-class 

subtype-of 

ContextRef 

Vcir  Enumeration 

obj  ect-class 

subtype-of 

ShorthandRef 

var  Tuple-Obj 

object-class 

subtype-of 

ShorthandRef 

var  Union-Obj  . 

object-class 

subtype-of 

ShorthandRef 

var  OpDecl 

object-class 

subtype-of 

Unif ied-Object 

vax  Field 

object-class 

subtype-of 

Unif ied-Object 

var  Trait-Ref 

object-class 

subtype-of 

Unif ied-Object 

var  Trait-Ref 1 

object-class 

subtype-of 

Trait-Ref 

var  Trait-Ref2 

object-class 

subtype-of 

Trait-Ref 

Vcir  Renames 

object-class 

subtype-of 

Unif ied-Object 
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var  Renames 1 

object-class 

subtype-of 

Renames 

var  Renames 2 

obj  ect-class 

subtype-of 

Renames 

var  Replaces 

object-class 

subtype-of 

Unif ied-Object 

var  Parameter 

object-class 

subtype-of 

Unif ied-Object 

var  SortSet  ’ 

object-class 

subtype-of 

Unif ied-Object 

var  Op 

object-class 

subtype-of 

Unif ied-Object 

var  SimpleOp 

object-class 

subtype-of 

Op 

var  UserOp 

object-class 

subtype-of 

SimpleOp 

var  Multiply 

object-class 

subtype-of 

SimpleOp 

var  Addition 

object-class 

subtype-of 

SimpleOp 

var  Subtraction 

object-class 

subtype-of 

SimpleOp 

var  Divide 

object-class 

subtype-of 

SimpleOp 

var  LessThan 

object-class 

subtype-of 

SimpleOp 

var  LessThanEq 

object-class 

subtype-of 

SimpleOp 

var  Equality 

object-class 

subtype-of 

SimpleOp 

var  Great erThan 

object-class 

subtype-of 

SimpleOp 

var  Great erThanEq 

object-class 

subtype-of 

SimpleOp 

var  EqualSym 

object-class 

subtype-of 

SimpleOp 

var  NotEqual 

object-class 

subtype-of 

SimpleOp 

var  LogicalOp 

object-class 

subtype-of 

Op 

var  And-Qbj 

object-class 

subtype-of 

LogicalOp 

var  Qr-Obj 

object-class 

subtype-of 

LogicalOp 

var  Not-Obj 

object-class 

subtype-of 

LogicalOp 

var  Implies 

object-class 

subtype-of 

LogicalOp 

var  Identifier 

object-class 

subtype-of 

Unif ied-Object 

var  IdName 

object-class 

subtype-of 

Identifier 

var  IntExpr 

object-class 

subtype-of 

Identifier 

var  RealExpr 

object-class 

subtype-of 

Identifier 

var  Reservedid 

object-class 

subtype-of 

Unif ied-Object 

var  LInverse 

object-class 

subtype-of 

Reservedid 

var  Superstar 

object-class 

subtype-of 

Reservedid 

var  Bottom 

object-class 

subtype-of 

Reservedid 

var  Top 

object-class 

subtype-of 

Reservedid 

var  Superplus 

object-class 

subtype-of 

Reservedid 

var  genPartition 

object-class 

subtype-of 

Unif ied-Object 

var  Generators 

object-class 

subtype-of 

genPartition 

var  Partitions 

object-class 

subtype-of 

genPartition 

var  EqPart 

object-class 

subtype-of 

Unif ied-Object 

var  EqPart 1 

object-class 

subtype-of 

EqPart 

var  EqPaxt2 

object-class 

subtype-of 

EqPart 

var  Operator 

object-class 

subtype-of 

Unif ied-Object 

var  quantifier 

object-class 

subtype-of 

Unif ied-Object 

var  VarDcl 

object-class 

subtype-of 

Unif ied-Object 

var  equation 

object-class 

subtype-of 

Unif ied-Object 

var  equivEqn 

object-class 

subtype-of 

equation 
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var 

quant eq 

object-class 

subtype-of 

Unif ied-Ob j  ect 

var 

term 

object-class 

subtype-of 

Unif ied-Object 

var  andTerm 

obj  ect-class 

subtype-oi 

term 

var  orTerm 

object-class 

subtype-of 

term 

var  addTerm 

object-class 

subtype-of 

term 

var  subtractTerm 

object-class 

subtype-of 

term 

var  multiplyTerm 

object-class 

subtype-of 

term 

var  divideTerm 

object-class 

subtype-of 

term 

var  tupleTerm2 

obj  ect-class 

subtype-of 

term 

var  bracket edTerm 

object-class 

subtype-of 

term 

var  notTerm 

object-class 

subtype-of 

term 

var  operationTerm 

object-class 

subtype-of 

term 

var  operationTerml 

:  object-class  subtype 

-of  operationTerm 

var  operationTerm2 

:  obj  ect-class  subtype- 

-of  operationTerm 

var  specialTerm 

object-class 

subtype-of 

term 

var  simpleTerm 

object-class 

subtype-of 

term 

var  tupleTerml 

object-class 

subtype-of 

term 

var  ItTerm 

object-class 

subtype-of 

term 

var  IteTerm 

object-class 

subtype-of 

term 

var  gtTerm 

object-class 

subtype-of 

term 

var  gteTerm 

object-class 

subtype-of 

term 

var  eqTerm 

object-class 

subtype-of 

term 

var  notEqTerm 

object-class 

subtype-of 

term 

var  impliesTerm 

object-class 

subtype-of 

term 

var  simpleOpTerm 

object-class 

subtype-of 

term 

var  simple0pTerm2 

object-class 

subtype-of 

term 

vax  ifStatement 

object-class 

subtype-of 

term 

var  ifTerm 

object-class 

subtype-of 

ifStatement 

var  elseTerm 

object-class 

subtype-of 

ifStatement 

var  thenTerm 

object-class 

subtype-of 

ifStatement 

var 

expression 

object-class 

subtype-of 

Unif ied-Object 

var  bracket edExpr 

object-class 

subtype-of 

expression 

var  primeiryExpr 

object-class 

subtype-of 

expression 

var  Exprl 

object-class 

subtype-of 

primaryExpr 

Veir  Expr2 

object-class 

subtype-of 

primaryExpr 

Vcir  Expr3 

object-class 

subtype-of 

primaryExpr 

var  Expr4 

object-class 

subtype-of 

primaryExpr 

var  ExprS 

object-class 

subtype-of 

primaryExpr 

vax 

barmarker 

object-class 

subtype-of 

Unif ied-Ob j  ect 

VcLX 

Consequences  : 

object-class 

subtype-of 

Unif ied-Object 

var  Consequences 1 

object-class 

subtype-of 

Consequences 

var  Consequences2 

object-class 

subtype-of 

Consequences 

var  Conversion 

object-class 

subtype-of 

Unif ied-Object 

var  Exempting 

object-class 

subtype-of 

Unif ied-Object 

var 

ConseqPart  : 

object-class 

subtype-of 

Unif ied-Object 
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var  ConseqPartl 
var  ConseqPart2 


:  object-class  subtype-of  ConseqPart 
:  object-class  subtype-of  ConseqPart 


5^ - — 

’/,  Unified  Model  Attribute  Declarations  for  Branches  in  Tree  Structure 

I - - - 

var  theory-types  :  map(DomainTheory,  set(DomainTheoryTypes)) 

computed-using  theory-types (x)  =  {} 

'/,var  theory-types  :  map(DomainTheory,  seq(DomainTheoryTypes) )  =  {||} 


var  theory-id 
var  ot-id 
var  dt-id 
var  ft-id 


:  map(DomainTheoryTypes,  IdName)  =  -Cl  l> 

:  map(DomainTheoryTypes ,  IdName)  =  {ll} 
:  map(DomainTheoryTypes ,  IdName)  =  {ll} 
:  map(DomainTheoryTypes,  IdName)  =  {||} 


var  theory-body 
var  ot-body 
var  dt-body 
var  ft-body 


:  map(DomainTheoryTypes,  TheoryBody)  =  {11} 

;  map(DomainTheoryTypes,  TheoryBody)  =  {|  1} 
:  map(DomainTheoryTypes,  TheoryBody)  =  {| 1} 
;  map(DomainTheoryTypes,  TheoryBody)  =  {| 1} 


var  theory-decl 
var  context-refs 

var  signature-decl 

var  theory-axioms 


map (TheoryBody,  TheoryDecl)  =  {|  1} 
map(TheoryDecl,  set(ContextRef )) 
computed-using  context-ref s(x)  =  {} 
map (TheoryDecl,  SignatureDecl)  =  {11} 

map (TheoryBody ,  set(TheoryAxioms)) 
computed-using  theory-axioms (x)  =  {} 


- 

’/,  Larch  Attribute  Declarations  for  Branches  in  Tree  Structure 


'/. - 

var  id 

var  trait-id 
var  parameter-id 
var  sort-id 
var  old-name- id 
var  new-name-id 
var  op- id 
var  simple-id 
var  simple-id2 
var  element-ids 
var  trait-ids 
var  sort-ids 
var  Vcir-id 
Vcir  var-ids 
var  field-id 
var  field-ids 
var  domain-ids 
var  range-id 
var  reserved-id 


map(Unif ied-Object , 
map(Unif ied-Object , 
map (Unif ied-Object , 
map (Unif ied-Obj  ect , 
map (Unif ied-Obj  ect , 
map (Unif ied-Obj ect , 
map (Unif ied-Obj  ect , 
map (Unif ied-Obj  ect , 
map (Unif ied-Obj  ect , 
map (Unif ied-Obj  ect , 
map (Unif ied-Obj  ect , 
map (Unif ied-Obj  ect , 
map (Unif ied-Obj  ect , 
map (Unif i ed-Ob j  ect, 
map (Unif ied-Object , 
map (Unif ied-Obj  ect , 
map (Unif i ed-Ob j  ect , 
map (Unif ied-Obj  ect , 
map (Unif ied-Obj  ect , 


IdName)  =  { I  I } 
IdName)  ={11} 
NameObj )  =  {11} 
IdName)  =  { I  I } 
NameObj)  =  {| 1} 
NameObj)  =  {11} 
IdName)  =  {| 1} 
Identifier)  =  {| |} 
Identifier)  =  {11} 
5eq(IdNcime) )  =  {||} 
seq(IdName))  =  {||} 
seq(IdName))  =  {||} 
IdName)  =  { I  I } 
seq(IdName))  =  {| 1} 
IdName)  =  { I  I } 
seq(IdName))  ={11} 
seq(IdName))  =  {||} 
IdName)  =  {1 1} 
Reservedid)  =  {I  1} 
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\ 


var  int 
var  num-real 


:  mapCUnif ied-Obj ect ,  integer)  =  {||> 
:  mapCUnif ied-Obj ect,  real)  =  {11} 


var  trait -parameter 
var  lield-defs 
var  sort-def 


:  map(DomainTheoryTypes,  seq(Parameter))  =  {I  1} 
:  mapCUnif ied-Obj ect,  seq(Field))  =  {|  1} 

:  mapCUnif ied-Obj ect,  SortSet)  =  {||} 


var  op-decls 


:  mapCSignatureDecl,  setCOpDecl)) 
compnted-using  op-decls Cx)  =  {} 


var  traitref 
var  renaming 
var  replacement 


:  mapCUnif ied-Obj ect,  seqCTrait-Ref ) )  =  {||} 
:  mapCTrait-Ref ,  Renames)  =  {||} 

:  mapCUnif ied-Obj ect,  seqCReplaces) )  =  {| 1} 


var  any-op 
var  simple-op 
var  simple-ops 
var  logical-op 
var  Ihs-marker 
var  rhs-marker 
var  if-marker 
var  then-marker 
var  else-marker 
var  markers 
var  open-sym 
var  close-sym 
var  name- id 
var  name-ids 
var  op-form 


mapCUnif ied-Obj  ect , 
mapCUnif ied-Obj  ect , 
mapCUnif ied-Obj  ect , 
map  C  Unif i ed-Ob j  ect, 
map  CUnif ied-Obj  ect , 
map  CUnif ied-Obj  e  ct , 
mapCUnif ied-Obj ect , 
mapCUnif ied-Obj ect , 
map  CUnif ied-Obj  ect , 
map  CUnif ied-Obj  ect , 
map  CUnif ied-Obj  ect , 
map  CUnif ied-Obj  ect , 
map  C  Unif i ed-Ob j  ect, 
mapCUnif ied-Obj ect , 
mapCNameObj,  OpForm 


Op)  =  {|  l> 

SimpleOp)  =  {| 1} 
seqCSimpleOp))  =  {| 1} 
LogicalOp)  =  {| l> 
MarkerSym)  =  {| |} 
McurkerSym)  =  {11} 
MarkerSym)  ={11} 
MarkerSym)  =  {|  1} 
MarkerSym)  =  {| 1} 
seqCMarkerSym))  =  {11} 
OpenSym)  =  { I  I } 
CloseSym)  ={11} 
NameObj )  =  {11} 
seqCNameObj))  =  {||} 

I  =  {|  1} 


var  gen-Partition 
var  gen-Partitions 
var  op- er at or 
var  op-erators 
var  eq-partl 
var  eq-part2 
var  qu-antifier 
var  var-Dcl 
var  var-Dcls 
var  eq-uationsl 

var  eq-uations2 


mapCUnif ied-Obj ect,  genPartition)  ={11} 
mapCUnif ied-Obj ect,  seqCgenPartition) )  =  {1 1} 
mapCUnif ied-Obj ect.  Operator)  =  {11} 
mapCUnif ied-Obj ect,  seqCOperator) )  =  {11} 
mapCTheoryAxioms,  EqPart)  =  {11} 
map C Cons eqPart2,  EqPart)  =  {11} 
mapCUnif ied-Obj ect.  Quantifier)  =  {11} 
mapCUnif ied-Obj ect,  VarDcl)  =  {| 1} 
map CUnif ied-Obj ect,  seqCVarDcl))  =  {11} 
mapCEqPart,  setCequation)) 
computed-using  eq-uationsl Cx)  =  {} 
map C Cons eqPartl,  setCequation)) 
computed-using  eq-uations2Cx)  =  {} 


var  Ihs-term 

var  rhs-term 

var  te-rm 

var  te-rms 

Vcir  bracket  ed-term 

var  if-Term 

var  then-Term 


:  mapCUnif ied-Obj ect, 
:  mapCUnif ied-Obj ect, 
;  mapCUnif ied-Obj ect , 
:  mapCUnif ied-Obj ect, 
:  mapCUnif ied-Obj ect, 
:  map CUnif ied-Obj ect, 
:  mapCUnif ied-Obj ect. 


term)  ={11} 
term)  ={11} 
term)  =  {1  1} 
seqCterm))  =  {| 1} 
bracket edTerm)  =  {11} 
term)  =  {| 1} 
term)  ={11} 
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var  else-Term 


:  mapCUnif ied-Object ,  term)  =  ^l l> 


var  args 
var  arg-1 
var  arg-2 
var  arg-3 
var  arg 

var  bracket ed-arg 

var  quant-eq 

var  not-op 
Vcir  neg-sign 


:  map (Unil ied-Object, 
;  map(Uniiied-Object , 
:  map(Uniiied-Object , 
:  map(Unified-Object, 
:  map(Unif ied-Object , 
:  map (Unif ied-Object, 

:  map (Unif ied-Object , 

:  map (Unif ied-Object, 
:  map (Unif ied-Object , 


seq(expression) )  =  {11} 
primaryExpr)  =  { I  I } 
primaryExpr)  =  { I  I } 
term)  ={11} 
expression)  =  {| 1} 
bracketedExpr)  =  {||} 

seq(quanteq))  =  {| 1} 

Not-Obj)  =  {| 1} 
Subtraction)  =  {11} 


var  con-sequences 
var  con-version 
var  ex-empting 
var  conseq-part 


:  map(TheoryBody,  Consequences)  =  {|  1} 

:  map(Unified-Object,  Conversion)  ={11} 
:  map (Unif ied-Object,  Exempting)  =  {||} 

:  map(Consequences,  ConseqPart)  =  {11} 


5^ - 

y.  Structure  for  Abstract  Syntax  Tree 


form  Def ine-Tree-Attributes-of-Unif ied-Specification 
Def ine-Tree-Attributes( ’DomainTheory ,  {'theory-types})ft 

Def ine-Tree-Attributes( ’ObjectTheory,  {’theory-id,  ’trait-parameter,  ’ theory-body})* 

Def ine-Tree-Attributes( ’DynamicTheory ,  {’theory-id,  ’trait-parameter,  ’theory-body})* 

Def ine-Tree-Attributes( ’FunctionalTheory ,  {’theory-id,  ’trait-parameter,  ’theory-body})* 
Def ine-Tree-Attributes( ’TheoryBody,  {’theory-decl,  ’theory-axioms, 

’ con-sequences})* 

Def ine-Tree-Attributes( ’TheoryDecl,  {’context -refs,  ’signature-decl})* 
y,  Define-Tree-Attributes(’TheoryAxioms,  {’gen-Partitions ,  ’qu-antif ier ,  ’ eq-uations})* 

Def ine-Tree-Attributes( ’TheoryAxioms ,  {’gen-Paxtitions,  ’ eq-partl})* 

y.y.  Lcirch  Identifier  Specializations 

Def ine-Tree-Attributes( ’Parameter ,  {’peirameter-id,  'sort-def})  * 

Def ine-Tree-Attributes( ’NameObj 1 ,  {’op-id})* 

Def ine-Tree-Attributes( ’Name0bj2,  {’op-form})& 

Define-Tree-Attributes( ’OpForm-1,  {’if-marker,  ’ then-mairker ,  ’else-marker})* 

Def ine-Tree-Attributes( ’OpForm-2,  {’Ihs-marker ,  ’any-op,  ’rhs-marker})& 
Define-Tree-Attributes(’0pForm-3,  {’Ihs-marker,  ’open-sym,  ’markers, 

’close-sym,  ’rhs-marker})* 

Def ine-Tree-Attributes( ’OpForm-4,  {’Ihs-marker,  ’field-id})& 

Define-Tree-Attributes( ’OpForm-5,  {’Ihs-marker,  ’rhs-marker,  ’reserved-id})* 

Def ine-Tree-Attributes ( ’ OpForm-6 ,  { ’reserved- id})* 

Def ine-Tree-Attributes( ’SortSet ,  {’domain-ids,  ’range-id})* 

y.y.  Larch  Operation  Declarations  Specializations 

Def ine-Tree-Attributes( ’SignatureDecl,  {’op-decls})& 

Def ine-Tree-Attributes( ’OpDecl,  {’name-ids,  ’sort-def})& 

y.y.  Larch  Context  References  Specializations  -  External  notations 
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Def ine-Tree-Attributes ( ' Includes ,  {’traitref })& 

Def ine-Tree-Attributes ( 'Assumes ,  {’traitref})& 

Larch  Context  References  Specializations  -  Shorthand  notations 
Def ine-Tree-Attributes ( 'Tuple-Qbj ,  {’sort-id,  'f ield-def s}) & 

Def ine-Tree-Attributes( 'Union-Obj ,  {’sort-id,  ’f ield-def s})& 

Def ine-Tree-Attributes( ’Enumeration,  {’sort-id,  ’element-ids})& 

Def ine-Tree-Attributes (’Field,  {’field-ids,  ’sort-id]-)ft 
Def ine-Tree-Attributes( ’Trait-Ref 1,  {’trait-id,  ’renaming})^ 

Def  ine-Tree-Attributes ( ’Trait-Ref 2,  {’trait-ids,  ’renaming})* 

Def ine-Tree-Attributes ( ’ Renames 1 ,  { ’ replacement} ) * 

Def ine-Tree-Attributes( ’Renames2,  {’name-ids,  ’replacement})* 
Define-Tree-Attributes( ’Replaces,  {’nes-name-id,  ’old-name-id,  ’sort-def})* 

*/,*/,  Larch  Generated  Partitions  Specializations 

Def ine-Tree-Attributes( ’Generators,  {’sort-id,  ’op-erators})* 

Def ine-Tree-Attributes ( ’Partitions,  {’sort-id,  ’op-erators})* 

Def ine-Tree-Attributes ( ’Operator ,  {’name-id,  ’sort-def})* 

*/,*/,  Larch  Axiomatic  Equations  Specializations 

Def ine-Tree-Attributes ( ’EqPartl ,  {’eq-uationsl})* 

Def ine-Tree-Attributes( ’EqPart2,  {’qu-antif ier,  ’eq-uationsl})* 

Def ine-Tree-Attributes( ’Quantifier,  {’Vcir-Dcls})* 

Def ine-Tree-Attributes( ’VarDcl,  {’var-ids,  ’sort-id})& 

Def ine-Tree-Attributes( ’equivEqn,  {’Ihs-term,  ’rhs-term})* 
Define-Tree-Attributes(’impliesTerm,  {’arg-1,  ’arg-2})* 

Def ine-Tree-Attributes( ’andTerm,  {’arg-1,  ’arg-2})* 

Def ine-Tree-Attributes( ’orTerm,  {’arg-1,  ’arg-2})* 

Def ine-Tree-Attributes ( ’addTerm,  {’arg-1,  ’arg-2})ft 
Define-Tree-Attributes( ’subtractTerm,  {’arg-1,  ’arg-2})* 

Def ine-Tree-Attributes ( ’multiplyTerm,  {’arg-1,  ’arg-2})* 

Def ine-Tree-Attributes( ’divideTerm,  {’arg-1,  ’arg-2})ft 
Define-Tree-Attributes(’simpleTerm,  {’cirg-1,  ’bracketed-cirg})* 

Def ine-Tree-Attributes( ’specialTerm,  {’arg-1,  ’arg-2})ft 
Def ine-Tree-Attributes( ’notTerm,  {’not-op,  ’lhs-term})ft 
Def  ine-Tree-Attributes ( ’simpleOpTerm,  {’simple-op,  ’Ihs-term})* 

Def ine-Tree-Attributes ( ’bracketedTerm,  {’ bracket ed-arg})* 
Define-Tree-Attributes(’operationTerm,  {’arg-1,  ’op-id,  ’arg-2})* 

Def ine-Tree-Attributes ( ’ItTerm,  {’eirg-l,  ’arg-2})* 

Def ine-Tree-Attributes( ’IteTerra,  {’arg-1,  ’arg-2})ft 
Def ine-Tree-Attributes ( ’gtTerm,  {’cirg-1,  ’arg-2})ft 
Def  ine-Tree-Attributes( ’gteTerm,  {’eirg-l,  ’cirg-2})ft 
Define-Tree-Attributes( ’eqTerm,  {’arg-1,  ’arg-2})* 

Def ine-Tree-Attributes( ’notEqTerm,  {’arg-1,  ’arg-2})* 

Def ine-Tree-Attributes( ’ if Statement ,  {’if-Term,  ’then-Term,  ’else-Term})* 

Def ine-Tree-Attributes( ’Exprl ,  {’te-rm,  ’simple-id})* 

Def ine-Tree-Attributes( ’Expr2,  {’simple- id})* 

Def ine-Tree-Attributes( ’ExprS,  {’simple-id,  'cirgs,  ’simple-id2})* 
Define-Tree-Attributes( ’Expr4,  {’sort-id,  ’field-id})* 

Def ine-Tree-Attributes( ’bracketedExpr,  {’open-sym,  ’te-rms,  ’close-sym,  ’arg-2})* 
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’/,*/,  Larch  Consequences  -  checkable  properties 

Define-Tree-Attributes(’Consequencesl,  {’traitrel,  ’conseq-part,  ’ con-version})& 
Def ine-Tree-Attributes( ’ConseqPartl,  {’gen-Partitions ,  ’ eq-uations2})& 

Dei ine-Tr ee-Attributes ( ’ Cons eqPart2 ,  { ’ gen-Part it ions ,  ’ eq-part2} ) & 

Def ine-Tree-Attributes( ’Conversion,  {’op-erators,  ’ex-empting})& 
Define-Tree-Attributes( ’Exempting,  {’qu-antif ier,  ’te-rms}) 


H-9 


Appendix  1.  RefinE  Code  for  the  ULarch  Grammar 


The  following  Refine  specification  defines  the  ULarch  Grammar.  The  grammar 
uses  the  unified  domain  model  and  the  Larch  extensions  (found  in  Appendices  F  and  H) 
to  construct  its  production  rules.  In  addition  to  incorporating  l^TgX  specific  notations, 
the  ULarch  grammar  uses  the  same  common  core  objects  and  attributes  as  the  UZgram- 
mar  to  promote  the  notion  of  language  inheritance.  The  production  rules  demonstrate 
Dialect’s  use  of  object  classes  and  attributes  to  form  grammar  rules.  This  approach  is 
more  intuitive  simplifying  a  developer’s  task  for  forming  tokens  and  creating  a  hierarchical 
structure  for  a  formal  language. 


! !  in-package ("RU") 

!!  in-greunmar( ’user) 

#1  I 

File  name:  ularch-gram.re 

1  I# 

! ! in-grammar ( ' syntax) 

grammar  Ularch 

start-classes  DomainTheory 
file-classes  DomainTheory 
no-patterns 

comments  matching  " 

ti 

case-sensitive 

symbol-continue-chars 

"abcdefghijklmnopqr3tuvwxyzABCDEFGHIJKLMN0PqRSTUVWXYZ0123456789_=" 

symbol-start-chars 

"  abcdef ghi j  klmnopqrstuvwxyzABCDEFGHI JKLMNOPQRSTUVWXYZO 1 23456789_=" 
productions 

DomainTheory  ::=  [''Wdocumentstyleflullpage,  larch]  {article}" 

"\\begin{document>"  theory-types  +  "\\\\" 

"\\end{document}"]  builds  DomainTheory, 

ObjectTheory  :  :=  ["\\begin{spec}  '/.ObjectTheory"  theory-id 

{[  "("  trait-parameter  +  ")"  ]}  "trait" 

theory-body 

"Wendfspec}"]  builds  ObjectTheory, 

DynamicTheory  : :  =  ["\\begin{spec}  ’/.DynamicTheory"  theory-id 
{[  "("  trait-parameter  +  ")"  ]}  ":"  "trait" 
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theory-body 

"\\end{spec}"]  builds  DynamicTheory, 

FunctionalTheory  :  ;=  ['’\\begin{spec}  ’/.FunctionalTheory"  theory-id 

{[  "("  trait-parameter  +  ")"  ]}  "trait" 

theory-body 

"\\end{spec}"]  builds  FunctionalTheory, 

TheoryBody  ::=  [theory-decl  theory-axioms  *  ""  {con-sequences}] 

builds  TheoryBody, 

'/,*/,  Formal  Parameters 

Parameter  ::=  [parameter-id  {[": "  sort-def]>]  builds  Parameter, 

SortSet  ;  :=  [domain-ids  *  ","  "->"  range-id]  builds  SortSet, 

NameObjl  ;:=  [op-id]  builds  NameObjl, 

Name0bj2  ::=  [op-form]  builds  Name0bj2, 

OpForm-1  ::=  ["if"  if-marker  "then"  then-marker 

"else"  else-marker]  builds  QpForm-1, 

OpForm-2  ::=  [{Ihs-marker}  any-op  {rhs-marker}]  builds  OpForm-2, 

OpForm-3  ::=  [{Ihs-marker}  open-sym  markers  *  ","  close-sym 

{rhs-marker}]  builds  OpForm-3, 

OpForm-4  ::=  [{Ihs-marker}  field-id]  builds  OpForm-4, 

OpenSyml  : : =  [  " ["  ]  builds  OpenSyml , 

0penSym2  ::=  [  "{"  ]  builds  0penSym2, 

□penSym3  ::=  [  "\\<"  ]  builds  0penSym3, 

CloseSyml  ::=  [  "]"  ]  builds  CloseSyml, 

CloseSym2  ::=  [  "}"  ]  builds  CloseSym2, 

CloseSym3  ::=  [  "\\>"  ]  builds  CloseSym3, 

MarkerSym  ;;=  [" _ "]  builds  MarkerSym, 

Typed  Expr  Productions 

IdName  ::=  [name]  builds  IdName, 

IntExpr  ::=  [int]  builds  IntExpr, 

RealExpr  : : =  [num-real]  builds  RealExpr , 

Theory  Declarations 

TheoryDecl  ::=  [context-refs  *  ""  {signature-decl}]  builds  TheoryDecl, 

•/.*/.  trait  body  COKTEXTREFs 
%*/,  external-refs 

Includes  ^  ::=  ["includes"  traitref  +  ","]  builds  Includes, 

Assumes  ::=  ["assumes"  traitref  +  ","]  builds  Assiunes, 

shorthand-refs 

Tuple-Obj  ;;=  [sort-id  "tuple"  "of"  field-defs  +  ","]  builds  Tuple-Obj , 

Union-Obj  :  :=  [sort-id  "union"  "of"  field-defs  +  ","]  builds  Unioh-Obj , 

Enumeration  : :=  [sort-id  "enumeration"  "of"  element-ids  +  ","]  builds  Enumeration, 

Field  ::=  [field-ids  +  ","  sort-id]  builds  Field, 

Trait-Refl  ::=  [  trait-id  {["("  renaming  ")"]}]  builds  Trait-Refl, 

Trait-Ref 2  ::=  ["("  trait-ids  +  ","  ")"  {["("  renaming  ")"]}]  builds  Trait-Ref 2, 
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Renames 1  : :=  [replacement  +  {  "  "  }]  builds  Renames 1, 

Renames2  ::=  [name-ids  +  {[","  replacement  +  ","]}] 

builds  Renames2, 

Replaces  ::=  [old-name-id  "for"  new-name-id  {[":"  sort-def]>] 

builds  Replaces, 

y,’/.  Signature  Declarations 

SignatureDecl  ::=  ["introduces"  op-decls  +  ""]  builds  SignatureDecl , 
OpDecl  ;:=  [name-ids  +  sort-def]  builds  OpDecl, 

TheoryAxioms 

TheoryAxioms  ::=  ["asserts"  gen-Partitions  *  ""  eq-partl] 

builds  TheoryAxioms, 

Generators  ::=  [sort-id  "generated  by" 

op-erators  +  ","]  builds  Generators, 

Partitions  ::=  [sort-id  "paurtitioned  by" 

op-erators  +  ","]  builds  Peirtitions, 

Operator  ::=  [name-id  ■[[";"  sort-def]}]  builds  Operator, 

EqPartl  ::=  ["equations"  eq-uationsl  +  ";"]  builds  EqPartl, 

EqPart2  : [qu-eintif ier  eq-uationsl  +  ";"]  builds  EqPart2, 

Quantifier  ;  :=  ["Wforall"  var-Dcls  +  ","]  builds  Quantifier, 

VarDcl  ::=  [var-ids  +  ","  sort-id]  builds  VarDcl, 

equivEqn  : :=  [Ihs-term  {["=="  rhs-term]}]  builds  equivEqn, 

notTerm  ::=  [not-op  Ihs-term]  builds  notTerm, 

simpleOpTerm  ::=  [simple-op  {Ihs-term}]  builds  simpleOpTerm, 

andTerm  ::=  [arg-1  "Wand"  arg-2]  builds  andTerm, 

orTerm  ::=  [arg-1  "Wor"  arg-2]  builds  orTerm, 

ifStatement  ::=  ["if"  if-Term  "then"  then-Term  "else" 

else-Term]  builds  ifStatement, 

impliesTerm  ::=  [arg-1  "Wimplies"  arg-2]  builds  impliesTerm, 

’/,  impliesTerm  ::=  [arg-1  "Wimplies"  arg-3]  builds  impliesTerm, 

*/,  here  arg-3  is  mapped  to  a  term.  This  reduces  one  layer  of  ()  but 
'/,  increases  the  recursive  layers  mciking  the  tree  deeper. 
addTerm  ::=  [arg-1  "+"  arg-2]  builds  addTerm, 

subtractTerm  ,  ::=  [arg-1  "-"arg-2]  builds  subtractTerm, 

multiplyTerm  ::=  [arg-1  arg-2]  builds  multiplyTerm, 

divideTerm  ::=  [cirg-1  "/"  arg-2]  builds  divideTerm, 

operationTerm  ::=  [arg-1  "W"  op-id  {cirg-2}]  builds  operationTerm, 
specialTerm  ::=  [arg-1  "II"  axg-2]  builds  specialTerm, 

simpleTerm  : :=  [arg-1  {bracketed-arg}]  builds  simpleTerm, 

bracket edTerm  : :=  [bracket ed-zurg]  builds  bracket edTerm, 

ItTerm  ;:=  [arg-1  "<"  arg-2]  builds  ItTerm, 
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